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)
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).
Now, the functional form (ifthen(), iif() or whatever) is not consistent with the
semantics of other functions, namely that all arguments are evaluated.
Opinions on the importance of this argument may vary, but it must not be
ignored.
Since the functional form (IfThen) violates above rule, it was removed again.
Sven did not feel like introducing the a ? b : c syntax, so it was not added.
If someone feels like submitting a patch that implements a ? b : c, it may well be taken under advisement.
I heard no-one speaking out clearly against the actual functionality (well, maybe one) or the a ? b : c form.
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.
'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 ;
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;
The last construct works more or less in C-like languages, because they mostly
require brackets in the if(), clearly separating the if from the conditional :
if (a?b:c?e:g) {
} if (h?i:j) {
}
(whether or not one actually wants to use/read this even in C is another matter)
Then, let me point out also that the gain of this construct in terms of
functionality may well be marginal.
Introducing the following generic function:
Generic function IIF<t>(Const Cond: Boolean; Const ATrueValue,AFalseValue : T)
: t; inline;
(name and exact declaration may well differ, and Sven still needs to fix some
inline bug)
Will solve most likely most of the use cases. I am not really a fan of generics,
but the above demonstrates its power clearly.
The only use case that would be gained is the non-evaluation of one of the
arguments.
To introduce a highly controversial construct for maybe marginal gain is not
advisable.
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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
