Anonymous function syntax

[Jacob Carlborg]

On 2011-09-23 10:50, Christophe wrote:
> 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.

I wouldn't say it's abusing the syntax.

> 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.

Yeah, I know.

-- 
/Jacob Carlborg