No, the second is always better because safer.

x := iif (Obj = nil, 0, Obj.Value);
This will raise access violation as a normal function or you depend on compiler implementation for this special case. And you should remember an additional special case of function.

x := iif Obj = nil then 0 else Obj.Value;
Doesn't raise AV because it's a statement, not function.

Regards,
Serguei

It is not a statement, it is an expression.

I prefer
   x := iif Obj = nil then 0 else Obj.Value;
over
   x := if Obj = nil then 0 else Obj.Value;

Because it clearly differentiates between if (a statement) and iif (an expression)

So the iif in either functional or expression form has my vote.

Michael.

And it could be extended to
"
V:= case i1 of
     1: 'one';
     2: 'two';
     else 'none';
    end;
"
In my opinion there should be as less intrinsics as possible. In MSElang I
even try to get rid of "writeln()" as compiler intrinsic.

Martin

Michael Van Canneyt wrote

So the iif in either functional or expression form has my vote.

I'm surprised that you support iif in function call form. Making something that looks like a function call but may not behave as a function call (short cut eval) seems like a recipe for disaster. Say what you will about the C ternary operator, but at least it didn't introduce ambiguity.

Henry

Would you mind explaining why ?

The compiler people also say this, but I never understood this argument.

Michael.

compiler implementation for this special case. And you should remember an additional special case of function.

That's why the current IfThen() is an intrinsic, to allow this.

x := iif Obj = nil then 0 else Obj.Value; Doesn't raise AV because it's a statement, not function.

It's not a statement, it's an expression. Also I won't introduce a new keyword ("iif") just for this.

Regards,
Sven

I'm rather less happy with this because of the difficulty of inserting inline assertions etc. to catch unexpected values.

When you call a function all the arguments get evaluated before the function gets called. iif will look exactly like a function call, but all the arguments may not be evaluated (that's the point, right). This is inconsistent and ambiguous, two things that pascal tries to eschew.

Even worse is that it's not a reserved symbol, so it can still be overridden. A call to iif in one unit may evaluate all its arguments, while it may not in another unit.

Pascal is not a language full of programmer traps, let's try not to add any!

Henry

Well, see my reply about 'robust' code for an observation about these details.

Michael.

+1

And why not use 'inline'?

  x := inline if Obj = nil then 0 else Obj.Value;

It's not necessary add one more keyword like "iif", I think.

Best regards,
Marcos Douglas

Michael Van Canneyt wrote on Tue, 02 Feb 2016:

You only talked about the order of evaluation in that mail, while Henry is talking about whether the arguments are parameter evaluation order issue is irrelevant in this context: Delphi guarantees left-to-right (or used to anyway, this may have changed), FPC doesn't guarantee anything.

There is, however, nothing fragile about writing code that assumes that all arguments to a function/intrinsic are evaluated exactly once (not more, not less), before the function is called, because they may have side-effects. Our optimisation passes in the compiler also go to great trouble to keep this property. You may not care about whether or not all of the arguments to a function are evaluated or not, but it's pretty fundamental.

As was mentioned on the core list, there are currently two exceptions to this rule:
a) assert, because of its C-macro origin (it only evaluates the second argument if the first evaluates to true)
b) read(ln)/write(ln), because e.g. writeln(x,y,z) is specified in the original Pascal standard as being equivalent to

   write(x);
   write(y);
   write(z);
   writeln;

(which means that if e.g. y is a function call and you also write something inside that function, it will appear after x has been written -- while it would appear before if writeln observed the normal function call semantics)

As Henry noted, depending on whether you will be using the built-in iif/ifthen intrinsic or an iif/ifthen defined in another unit, whether or not all arguments will be evaluated changes (this also holds for assert, FWIW). That is not good, especially since in pretty much all other languages that have an ifthen/iif intrinsic, all arguments /are/ always evaluated (unlike with assert in other languages).

Jonas

There you talk about order of evaluation, which is irrelevant to what I'm trying to say. Maybe I'll try an example to explain what I'm on about.

Say you have code like this:

IfThen(IsSomething, MungeA(A), MungeB(B));

Currently MungeA(A) and MungeB(B) are called, irrespective of the value of IsSomething. The order is irrelevant (I always assumes that it was undefined, like in C) and I agree that it's wrong to rely on.

If you replace it with the new IfThen (or iif), only MungeA(A) _or_ MungeB(B) will be called. This is exactly what you want from a conditional operator.

The conditional operator shouldn't look like a function call, because it doesn't act like a function call: it will not evaluate all its arguments. Again: nothing to do with order, it's whether they actually get evaluated in the first place.

Henry

but the exact same observation applies.

Michael.

Yes.
As I wrote to Jonas, it doesn't change one iota about my observation.

It only reminds me that I need to be more exact in my formulation.

Michael.

So you are saying that relying on all function arguments being evaluated is bad?

Henry

Sven Barth wrote

It's not a statement, it's an expression. Also I won't introduce a new keyword ("iif") just for this.

Thank you for this.

Marcos Douglas

On Tue, Feb 2, 2016 at 6:49 AM, Michael Van Canneyt wrote:
[...]

+1. The function is more clear to me too.

I am saying that the difference between this behaviour and the behaviour where they may not all be evaluated is so subtle that many (I am tempted to say most) programmers will never even know the difference.

It is simply over their heads.

Even Graeme - who has a lot of mileage in programming - was confused as to "why all the fuss" till I explained with a simple example.

The fact that this difference is so subtle, makes using this as an argument in the current discussion:

"iif(a,b,c)
is fundamentally different in behaviour from
functionxyy(a,b,c)"

simply laughable in my eyes, because likely 99,99% of programmers won't know the difference. As Graeme said: 'I guess I was just lucky it never happened to me'. That sums it up.

I'm just trying to to put any foaming-at-the-mouth argumentation using this particular argument in perspective.

For a correct understanding: The compiler must behave predictable at all times, no arguing there. But I don't think that iif() having different semantics than all other functions, is a problem. It just needs to be documented properly. It is a non-issue for me.

To give more perspective:
The same is true for Writeln() and Assert(), which also have are different semantics, but this difference is simply documented (if at all). I didn't hear anyone protesting that. The fact that it is so in the pascal standard doesn't make a iota of difference; the standard was most likely simply made after the facts.

Michael.

Michael Van Canneyt wrote on Tue, 02 Feb 2016:

[evaluating all arguments to a function/intrinsic]

I'm just trying to to put any foaming-at-the-mouth argumentation using this particular argument in perspective.

I think this is rather disingenuous after your own foaming-at-the-mouth hyperbole (?) of reverting all changes and temporarily shutting down the svn server if someone else did something that you considered to be fundamentally wrong.

For a correct understanding: The compiler must behave predictable at all times, no arguing there. But I don't think that iif() having different semantics than all other functions, is a problem.

Including all other functions called iif().

It just needs to be documented properly. It is a non-issue for me.

It is a deal breaker for me.

Jonas

2016-02-02 13:12 GMT+01:00 Michael Van Canneyt :

+1 well said.

profit of different behavior for iif is huge:

x := iif(obj = nil, 0, obj.foo);

and as was stated many times, this behavior iif is *compatible with existing Oxygene* (!). Finally some compatible part.

maybe is worth to implement additional IfThen intrinsic (just generic version of regular method from Math/StrUtils.IfThen)

Wow, what's this? I never knew this. I have been using Borland products since TP 1.0 and for me left-to-right is automatic, I don't even think about it. If FPC doesn't guarantee this my code is full of potential problems.
BTW using left-to-right does not mean non-robust code if it is guaranteed.

Andreas

Oh please...

If someone really thought that was serious: *it was hyperbole*.

It's just a discussion. We're not judging life and death here.

Hence the "in perspective".

Maybe you will want to shut down SVN if it is done differently from what you think is proper ? I'll give you the password ;-)

Michael.

Quick !
We should call the New York Times or Frankfurter Allgemeiner Zeitung, Martin just agreed with someone of the core team !!!

Michael.

hehe, "the plot thickens"

Pandora's box, anyone? :-)

Michael.

Agreed.

Martin

Andreas Berger wrote on Tue, 02 Feb 2016:

It also may have problems when compiling with the Delphi "NextGen" compiler: http://stackoverflow.com/a/11010685

Jonas

I'm sure most programmers will know that in foo(doa(), dob()) both doa() and dob() will be executed. I agree with what you said about the order of evaluation (it's undefined behaviour), but you said that your points still stand for whether arguments are doesn't
make any sense, how would the compiler decide what to evaluate and what not?

It is simply over their heads. Even Graeme - who has a lot of mileage in programming - was confused as to "why all the fuss" till I explained with a simple example.

I think there may be a misunderstanding. I'm very confident Graeme knows that all the arguments to a function gets evaluated and that a branch of an if statement won't be evaluated. Maybe he was confused by wrapping up the behaviour of an if statement into something that looks like a function?

I'm just trying to to put any foaming-at-the-mouth argumentation using this particular argument in perspective.

I've tried to express my concerns about this in a civil way, but I apologise if anything I've said came across otherwise.

Exceptions to standard behaviour is bad, just because there are exceptions doesn't mean that we need to create more of them. Documenting something doesn't make the behaviour intuitive.

Henry

There are not many occasions where I have fundamental other opinions than Jonas regarding FPC. Currently I can't remember a single instance.

Martin

Like Graeme said "I guess I have been lucky"! I have all printed documentation for the versions I bought from TP1 to Delphi 7, and it was always guaranteed. This sucks!!!

Andreas

For good understanding, I was not being serious.

Michael.

I was not referring to anyone in particular, and my writing style often tends to be hyperbole.

So please do not think it is necessary to apologize.

Michael.

It is guaranted for boolean operators with short-evaluation (if you mean this). See: http://www.freepascal.org/docs-html/ref/refsu48.html#x150-17200012.8.3  
V.
______________________________________________________________

Like Graeme said "I guess I have been lucky"! I have all printed documentation for the versions I bought from TP1 to Delphi 7, and it was always guaranteed. This sucks!!!

Andreas

Delphi guarantees left-to-right (or used to anyway, this may have changed), FPC doesn't guarantee anything.

> Wow, what's this? I never knew this. I have been using Borland products

since TP 1.0 and for me left-to-right is automatic, I don't even think about it. If FPC doesn't guarantee this my code is full of potential problems.

BTW using left-to-right does not mean non-robust code if it is guaranteed.

FPC indeed does not guarantee the evaluation order (and that's even documented AFAIK). It might change the evaluation order to generate better code. It only guarantees that each parameter is evaluated exactly once (though in case of expressions without calls it might reuse results in certain optimization settings, I don't know that currently though) and that the parameters are passed in the correct order.

Regards,
Sven

Not to my knowledge.

Well, it would be strange if it behaved otherwise :)

Michael.

I'd suspect that both if-else-experssion and iif() will end up being in the FPC.
Since it appears that preference is split exactly 50/50 over an expression and a function.

Similar to other duplication:
...in sets
Include(ch, 'a')

  ch:=ch+['a'];

...in arithmetical operations
   a:=a+4;
   inc(a,4);
   a+=4;   // C-style btw!

thanks,
Dmitry

(bikeshedding mode=on)

and what if the definition was

x := (if condition then value1 else value2);

that is REQUIRING round parentheses around this construct - no need for 'inline' keyword and compatible with code beautifiers (of sorts) and thanks to parentheses, showing exactly it's a statement, returning a value like an expression...

el es

To add to that...

i have seen (and used at start and still at times) coding the explicit order of calculations (like evaluating numerical expressions..) by inserting parentheses and not assuming the right order will be deduced by the compiler from 'just' writing the formula down in flattened form.

Newbie stuff, yes, but at least the order of parentheses-driven evaluation seems to be guaranteed and is relatively timeless... and language-agnostic, even the scripting slangs honour that.

I believe this kind of explanation of-sorts plays with what may be going on in this construct ?

el es