Anonymous function syntax

[Christophe]

"Martin Nowak" , dans le message (digitalmars.D:145287), a écrit :
>>> 4. The expression is badly delimited.
>>> The first rewrite symbol => expression
>>> is actually symbol => expression\{CommaExpression, CatExpression}.
>>>
>>> E.g.:
>>> dgs ~= (int a) => (a + 5) ~ (int a) => (a ^^ 2);

this is a compile time error, because you are appending an int (a+5) 
with a delegate ((int a) => (a^^2)).
You should write :
 dgs ~= [(int a) => a + 5), ((int a) => a ^^ 2)];

>>> foo(a, b => (log(b), b), c)
That seems fine to me.
> sort!((a, b) => a <= b)(input)
> vs.
> sort!((a, b) { a <= b })(input)
OK

> 
> static assert ((a, b) => a < b != (a, b) => a > b)

That is a compile time error too, because you use != on a boolean on one 
side, and on a delegate on the other side.
You have to use parenthesis arround the delegates to use an operator on 
them, otherwise the operator could be a part of the delegate.

static assert (((a, b) => a < b) != ((a, b) => a > b))

> vs.
> static assert ((a, b) {a < b} != (a, b) {a > b})
OK

> Another minor issue:
> a =>
>    a + 3
> Offers worse indentation for long expressions than
> (a) {
>    a + 3
> }
Why?

> We won't remove the existing function literal syntax due to code breakage.
> We won't remove the string predicates because they are still shorter.
> I am worried about having three subtly different language constructs for  
> the same concept.
> 
>      (a, b) { return a < b; } |      q{a < b}     | (a, b) => a < b
>         | old delegate syntax | string predicates | fat arrow delegates
>         |--------------------------------------------------------------
> scope  |    declaration      |   instantiation   |   declaration
> return |    explicit         |   implicit        |   implicit
> body   |    statements       |   expression      |   expression
> types  |    optional         |   no              |   optional
> 

Don't forget the return-omissing delegate syntax (a, b) { a < b } :P

Old delegate should be kept as the normal way to build a delegate. They 
are needed to make more than one-liners. Maybe optional types might be 
removed in the long term to make the language simpler, but they can't be 
removed.

In the long term (D>=3.0, not to break existing code), I am not sure it 
is worth keeping string predicates if delegates offer a convenient 
syntax. Moreover they are not a langage feature, they are a library 
feature. Nothing prevents people from writing a dozen syntax like that.

-- 
Christophe