Steve Yegge's rant on The Next Big Language

[Vassily Gavrilyak]

Strange, for me inferring RETURN type is much more difficult then argument type, 
and D already do exactly this.  
Arguments types are already declared, in declaration of map
R[] map(T[] arr, R delegate(T) fun);

>From here it is clear that there is one argument, and its type is T for array of T's.
But probably some D features will disallow such simple kind of inference.
Inferring type R from above example seems much more complicated - 
you need to look at the delegate code and find the return type.

> Whoa, now *that* is nasty.  Quick: is foo(a,b=>a>b) a delegate of two
> arguments or one?  What if a is declared outside the scope; which is it
Hmm, for me it looks simple :-)
It's a shortcut for delegate (int a, int b){return a>b;}
It's the same as lazy  3+2  is just a shortcut for (void){return 3+2;}, but with parameters.
>From expanded version it is clear that a and b are local arguments and normal D rules 
of name resolution is applied. (well, I do not know the exact rules, but it seems 
as it will be error having the same variable name upper in the scope).
Another similar example of already existing type inference is 
foreach(i, v; arr)
Here i and v are inferred from enumerated collection type, and map is actually the same
arr.map((i, v)=>v+v);

Hmm, but you are right with your question, it seems that parenthesis are mandatory 
because otherwise it will be impossible to differentiate how many arguments needed.
So the correct version will look like
auto sorted = sort(arr,  (a,b) => a<b );


> *groans*  My brain hurts just trying to think about it >_<
Ouch, I'm sorry for this. You give me a wonderful functools.d and I hurt your brain 
in response. Never wanted such thing to happen. 
But that are actual examples of how I am currently using functools.d :-).
Many thanks for this lib, it helps me a lot.

And that was actual example of C# 3.0 syntax.
Actually they implemented comprehensions too, but with somewhat strange "SQL-like"
syntax. So my example with such syntax will look something like:
var res = FROM [1,2,3] AS x SELECT x+x WHERE x<2 ORDER BY x;
It's probably more readable but that's totally different language, no spirit of C here.

To conclude - D needs parametrized lazy arguments and more aggressive type inference. 
It will cover most syntax sugar issues with array comprehensions and much more, 
because syntax will not be restricted.
Example I actually use often:
Given an array of people build an associative array with name as a key;
Person[char[]] peopleByName = people.hashBy((person)=>person.name);