retard wrote:
Mon, 07 Dec 2009 13:17:10 +0000, Michal Minich wrote:

Hello bearophile,

Michal Minich:

But introduction "{ epx }" as delegate/function literal for functions
with no arguments, which implicitly returns result of the expression,
seems to me as a good idea.

It's a special case, and special cases help to kill languages. It's not
important enough.
But a general shorter syntax for lambdas is possible, like the C# one.
Evaluations lazy arguments only 0 or 1 times sounds like a nice idea.
Bye,
bearophile
Yes, it works well in C#, and it is one of the best extension of this
language (only adding generics was better).

Consider how it works in C#, and how it could in D

// 1. lambda with no parameter
int a;
var t = new Thread (  () => a=42  );

// 2. lambda with one parameter
string[] arr;
Array.FindAll (arr, item => item.Contains ("abc"));
// 3. lambda with more parameters
Foo (  (a, b) => a + b );

You surely understand that Walter doesn't have enough time to change this before the Andrei's book is out. So D2 won't be getting this. Besides, he hasn't even said that he likes the syntax. And D can't infer the types that way, you would need

Foo (  (auto a, auto b) => a + b );

or

Foo (  [T,S](T a, S b) => a + b );

// 4. lambda with statement (previous examples were expressions)
Array.FindAll (arr, item =>  { return item.Contains ("abc"); } ); //
curly braces, semicolon and return are required when statement is used.

D could use:

1. auto t = new Thread ( { a=42 } );
or auto t = new Thread ( () { a=42 } );

2. array.findAll (arr, (item) { item.contains ("abc") } );

Andrei invented the string template parameter hack to avoid this. This would work too slowly since the dmd backend from the 1960s cannot inline anonymous functions. It can only inline named functions.

3. foo ( (a, b) { a + b } );

4. array.findAll (arr, (item) { return item.contains ("abc"); } );

I'm not proposing this syntax (maybe I probably should, but I have
feeling I would not be first). It may not even be possible to parse it,
but seems to me more similar to how currently functions are written. In
this setting {exp} or {stm} is not *special* case.

Actually, it can, and will, infer the types for (a, b) { ... }

It not doing so right now is on the bugzilla.

Reply via email to