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
