Inline If statement, i.e. IIF()?

[Zoran]

It's been more than eight years since PascalDragon implemented (in what was then trunk) and announced the IfThen intrinsic.
It was implemented so that only one of the two expressions gets evaluated, which cannot be done with a normal function.

Then other core developers didn't agree with it though. So it was removed from the fpc sources then.

See: https://lists.freepascal.org/pipermail/fpc-pascal/2016-January/046376.html

[MarkMLl]

I /thought/ I remembered that, and my sympathies are fully with Sven on this one: it's most unfortunate to have Pascal omit something which is standard in other ALGOL-derivatives.

I'm a bit troubled though: if the syntax "looks like a function", how is it possible to know that it's the "evaluate one but not both" wgich is being used rather than the "ordinary function" from strutils or maths?

MarkMLl

[Thaddy]

It was implemented so that only one of the two expressions gets evaluated, which cannot be done with a normal function.

But my version is accepted a few years ago. With the provision that it is a generic and therefor does not adhere to boolean shortcut evaluation, although I wish it did. Anyway It is there.

[PascalDragon]

It was implemented so that only one of the two expressions gets evaluated, which cannot be done with a normal function.

But my version is accepted a few years ago. With the provision that it is a generic and therefor does not adhere to boolean shortcut evaluation, although I wish it did. Anyway It is there.

It seems you don't have your terms right. Boolean shortcut evaluation is the case for the ordinary IfThen as well, because it only applies to the condition, just like in the if-statement. What is the important difference is whether the branches are both evaluated or only the one selected by the condition.

Code: Pascal  [Select][+][-]

1. program tifthen;
2.  
3. {$mode objfpc}
4.  
5. uses
6.   SysUtils;
7.  
8. type
9.   TTest = class
10.     f: LongInt;
11.   end;
12.  
13. var
14.   t: TTest;
15.  
16. procedure DoTest;
17. begin
18.   { with $B+ this would crash if t is Nil }
19.   Writeln(specialize IfThen<LongInt>(Assigned(t) and (t.f = 42), 1, 2));
20. end;
21.  
22. begin
23.   t := Nil;
24.   DoTest;
25.   t := TTest.Create;
26.   DoTest;
27.   t.f := 42;
28.   DoTest;
29. end.

I'm a bit troubled though: if the syntax "looks like a function", how is it possible to know that it's the "evaluate one but not both" wgich is being used rather than the "ordinary function" from strutils or maths?

If I'd do it again I'd just go with a if … then … else-expression. 🤷‍♀️

[MarkMLl]

I'm a bit troubled though: if the syntax "looks like a function", how is it possible to know that it's the "evaluate one but not both" wgich is being used rather than the "ordinary function" from strutils or maths?

If I'd do it again I'd just go with a if … then … else-expression. 🤷‍♀️

Which was of course the ALGOL way. In the general case (i.e. including later ALGOL derivatives), I've been troubled by that lacking an explicit end. However since it can't- by definition- omit the else I think that in terms of language consistency this is a a very minor sin.

But my version is accepted a few years ago. With the provision that it is a generic and therefor does not adhere to boolean shortcut evaluation, although I wish it did. Anyway It is there.

It seems you don't have your terms right. Boolean shortcut evaluation is the case for the ordinary IfThen as well, because it only applies to the condition, just like in the if-statement. What is the important difference is whether the branches are both evaluated or only the one selected by the condition.

That's something I tried to emphasise earlier in the thread. Many details are lost in the mists of time, but I've seen stuff which implied that- in effect- ALGOL expanded a complex boolean expression into a cascade of if-then-else statements, i.e. it was distinct from the sort of optimisation which would shortcircuit e.g. a := 0 * something();. But the concept of types in ALGOL-60 was very immature, I can't even remember without looking for documentation whether there was a boolean variable type per se or if types were merely there to distinguish between integers and floats.

MarkMLl

[PascalDragon]

I'm a bit troubled though: if the syntax "looks like a function", how is it possible to know that it's the "evaluate one but not both" wgich is being used rather than the "ordinary function" from strutils or maths?

If I'd do it again I'd just go with a if … then … else-expression. 🤷‍♀️

Which was of course the ALGOL way. In the general case (i.e. including later ALGOL derivatives), I've been troubled by that lacking an explicit end. However since it can't- by definition- omit the else I think that in terms of language consistency this is a a very minor sin.

That is my opinion as well that the “dangling else” problem isn't as problematic with the if-expression compared to the if-statement.