Why make the things complex? Why create another "special case"? Look at the "iif" as an statement and the things will be simple.

Disagreed.
The principal difference between the statement and the expression is that the expression doesn't control the execution flow. In this "expression" you simply hide the statement to the semantic analysis level.

Regards, Sven

Regards,
Serguei

BECAUSE. IT. IS. *NOT*. A. STATEMENT!
It never was and it never will be! It returns a value and thus by definition it is an expression!

Regards,
Sven

+1
And imho that why it is important that it does not look like a statement either, i.e. it does not start with a keyword.

also if we are discussing (are we?) a form like
   x:= iIf a>b  iThen c iElse b;
then why not
   x:=  a>b  ifThen c ifElse b;

What are the advantages/disadvantages they have over each other?

They both need operator precedence:
   x :=  iIf a Then b else c + 3;
should be which
   x :=  (iIf a Then b else c) + 3;
   x :=   iIf a Then b else (c + 3);

unless a closing "end" is enforced

   x:= iIf a>b  iThen c iElse b iEnd;

Which is what the function stile does implicitly, by having brackets around all 3 arguments.

------------------
Btw, just for fun, did some playing to see how much could be done with current fpc

program Project1;
{$mode objfpc}
{$MACRO on}
{$define ifthen:=and}
{$define ifelse:=or}
type TIfThen = record
   b:boolean;
   v:integer;
end;
operator and (a:boolean;b:integer):TIfThen;
begin
   result.b := a;
   result.v := b;
end;
operator or (a:TIfThen;b:integer):integer;
begin
   if a.b then
     result := a.v
   else
     result := b;
end;
begin
   writeln( (1<2) and 3 or 4 );
   writeln( (1>2) and 3 or 4 );
   writeln( (1<2) ifthen 3 ifelse 4 );
   writeln( (1>2) ifthen 3 ifelse 4 );
   readln;
end.

definition it is an expression!

> > +1 And imho that why it is important that it does not look like a statement

either, i.e. it does not start with a keyword.

Because I won't add new keywords just for this feature, especially if they are inside normal code (I'm a bit less strict outside of routine bodies ;) ).

Also in your second case especially the "ifThen" needs to be handled as an operator to avoid too big modifications of the parser that I don't see justified for something that should merely be a minor extension.

What are the advantages/disadvantages they have over each other?

The former is much more easy to add as my patch in the "if-then-else expression" thread shows. The other will be be more complicated.

Regards,
Sven

Ah, ok: "iif" (as none function) is of the table too. I had not gotten that from the discussion so far.

But fair enough, if they would become keywords, then I agree the impact on existing code would be potentially massive.

In this case, I dislike the
    x := if a then b else c;

While at first easier to read (no need to know that IfThen or IIF is an intrinsic), it resembles (I am aware it is not, but it still resembles) a statement, and opens the door to discussions that other statement should return values too.
Like x := y := 1; which is not desirable at all.

on, and on and on blah blah - lets move on!

Michael.

Martin wrote

In this case, I dislike the x := if a then b else c;

Why not as below, using 'inline' keyword?

   x := inline if a then b else c;
It is simple and elegant;
Is different than a simple 'if';
Could be used to extend 'case' too;
Don't looks like a function;
Don't collides with another function name.

Best regards,
Marcos Douglas

Is possible to close thread on mailing list?

-,-

Maciej Izak wrote

Is possible to close thread on mailing list? -,-

Simply do not open (and delete) mails with "IfThen" in subject.

because it still resembles a statement. (even so, I guess technically (with or without the inline, it actually is an operator, since its part of an expression)

And as pointed out the next would be "case of" or "inline case of". Again, it makes no difference if the "inline" prefix turns the statement keyword into an operator, or if this change is deducted from the fact that it is in a right hand site expression.
The result is one more expression that looks like statements can return values (or at least statements prefixed by "inline").

Now the below might seem totally exaggerated, but if the above applies to "if" and "case" then really why should it end there? It certainly did not end there in C.

Whats next? codeblocks? (anonymous functions are on the way anyway(afaik), so this is not very different)
x := inline begin {any pascal code/list of statement}; result := value; end; OUCH! (and caps dont even make that stand out enough)

Also there are many who want assignments
X := inline y := 1;
Now that might be looking nice if all you do is set 10 variables to 1. But
x := inline if inline y := foo() > inline z := bar() then inline m:= 1 else inline m:=2;
*OUCH*!!

-----------
about inlined codeblock (not that I would like it, but)

afaik anonymous functions may come in a form like

    x := function begin {...} end; // which will also be a closure.

then that would allow

    x := function begin {...} end(); // calling in in place, and assign

the result to x
which is really not much different to

    x := inline begin {...} end;

-----------
I would have as alternative to the function style prefered the operator without leading if (X:= a ifthen b ifelse c). But that requires new keywords, and will break a lot of code.
Basically anyone who has an identifier (variable, function, ...) called "ifthen"

As Sven wrote:
"Everything can be abused..."

But Ok, I understood your point.

Marcos Douglas