Anonymous function syntax

[Christophe]

Jacob Carlborg , dans le message (digitalmars.D:145083), a écrit :
> On 2011-09-22 22:54, Andrei Alexandrescu wrote:
>> On 9/21/11 5:17 PM, Walter Bright wrote:
>>> I've collected a few from various languages for comparison:
>> [snip]
>>
>> I think we should do the following:
>>
>> 1. Introduce a new token "=>"
>>
>> 2. Add this rewrite to the grammar:
>>
>> symbol => expression
>>
>> translates to
>>
>> (symbol) { return expression; }
>>
>> 3. Add this rewrite to the grammar:
>>
>> symbol1 symbol2 => expression
>>
>> translates to
>>
>> (symbol1 symbol2) { return expression; }
>>
>> 4. Add this rewrite to the grammar:
>>
>> (comma_separated_parms) => expression
>>
>> translates to
>>
>> (comma_separated_parms) => expression
>>
>> Each item in comma_separated_parms may be 1 or 2 symbols separated by
>> whitespace. Example:
>>
>> (int a, b) => a + b
>>
>> is valid and translates to (int a, b) { return a + b; }
>>
>> 5. The expression cannot contain commas at top level; an unparenthesized
>> comma is considered to finish expression, just like in a function call's
>> argument list. For example:
>>
>> fun(int a => a + 1, a + 2)
>>
>> is interpreted as
>>
>> fun((int a => a + 1), (a + 2))
>>
>> To use comma inside expression, add parens around it.
>>
>> 5. Remove bugs and limitations. A function literal may specify none,
>> all, or some parameter types, and the compiler correctly figures out the
>> appropriate template and non-template parameters. The literal
>> subsequently converts to function pointer or delegate whenever there's a
>> match of parameter and result types.
>>
>>
>>
>> Andrei
> 
> I like it.
> 
> Just to be clear, when having a parameter list of one parameter, the 
> parentheses are optional; and when having multiple parameters the 
> parentheses are mandatory?
> 
> Would any of these be allowed:
> 
> symbol => { expression } // braces, implicit return, no semicolon
> 
> symbol => { expression; } // if legal, would this return void or expression
> 
> symbol => expression; // semicolon
> 
> symbol => { return expression; } // braces, explicit return, semicolon
> symbol => return expression; // explicit return, semicolon
> 
> symbol => {
>      expression;
>      expression
> } // multi-line lambda, braces, implicit return, no semicolon

No, we should not kill a good syntax idea by giving ways to abuse it 
right away.

First implement "symbol => expresion"

Then see if it works well and if it should benefit from further 
improvement.

BTW, the main improvement is to avoid punctuation and return, so there 
is no gain to introduce them again.

-- 
Christophe