[fpc-pascal] IfThen() intrinsic removed

[Lukasz Sokol]

Hi,

On 04/02/16 21:33, Michael Van Canneyt wrote:
> 
> 
> On Thu, 4 Feb 2016, Felipe Monteiro de Carvalho wrote:
> 
>> Disappointed :(
> 
> Well, such is life. I'm also disappointed that my bank account doesn't contain millions. But I learned to live with it :-)
> 
> But all hope is not lost yet.
> 
>> Why was it done? I thought that pretty much everyone was in favor?
> 
> Not quite, form was also deemed important. It is a tricky balance.
> 
> To recapitulate:
> 
> There were various choices:
> 
> a) not adding at all
> b) a ? b : c
> c) if a then b else c
> d) iif()    (or some variant thereof)
  
what of
  e) some kind of assignment, requiring use of braces, e.g. 
   x :=  ( if condition then truevalue else flasevalue );
or
   x :=  ( condition then truevalue else falsevalue );

... ?

It also does not clash with function names, only reuses same keywords...

> 
> From the people that responded in the core discussion, the majority was for the a ? b : c
> syntax, or not adding at all (not all replied).
[...]

> Sven simply didn't want to implement the a ? b : c form.
> 
> This should be respected, each works on what (s)he wants to work.
> That is not to say that all work done is automatically and irrevocably added to the compiler.
> 
> Experiments can be done, but can also be discarded.


> 
>> It isn't very pascalish, that's true, but we could implement it like
>> the proposed "inline if A then B else C" syntax... which is very
>> pascalish and cool.

So might be the 'assignment', no?

> 
> 'Cool' is a very personal appreciation. Some men like blondes, others prefer redheads or brunettes.
> 
> For example, I don't think this is pascalish or cool.
> 
> Rationale for protest (there may have been other reasons beside the below):
> 
> "if then" is a statement. This is a clear and unambiguous rule.
> 
> Allowing "if then" as part of an expression is introducing ambiguity and error prone.
> 
> Samples of non-desirable constructs include:
> 
> Type
>   TMyArray = Array[1..if sizeof(integer)=2 then 4 else 5] of integer;
> 
>   myconst = if sizeof(integer)=2 then 4 else 5;
> 
>   Procedure Something(AA : Integer = if sizeof(integer)=2 then 4 else 5);
> 
>   Property A : Integer Index if sizeof(integer)=2 then 4 else 5 read geta;
> 
>   Property B : Integer Read FA Write FA default if sizeof(integer)=2 then 4 else 5 ;

I believe the assignment form would get rid of the above... because one can't use an := assignment in a declaration right?

> 
> And - in my eyes - the topper in horror:
> 
>   if if if a then b else c then e else g then
>      DoSomething
>   else if if h then i else j then
>      DoSomethingElse;
> 

and convert this into
x := (((a then b else c) then e else g) then DoSomething else DoSomethingElse);
(

....well actually looking at this abuse it doesn't seem to be likely to work ...?
unless someone does

x := (y := ( z := (a then b else c) then e else g ) then DoSomething else DoSomethingElse);

so the immediate y,z variables have to be declared.
(and also requires a,b,c,e,g be boolean)

but quoting "everything can (and will) be abused" duh ;)

[...]

> That about sums up what was said about this in core.
> 
> As you see, it is not necessarily permanently off the drawing board, but has definitely been put in the (deep) freezer.
> 
> Michael.

Just my PLN 0.02.

el es