Rant after trying Rust a bit

[Enamex via Digitalmars-d]

On Friday, 24 July 2015 at 21:44:42 UTC, Tofu Ninja wrote:
> But the part that I don't think makes sense for
>
>      auto a = {return 4;};
>
> to type "a" to a function pointer. I would expect {return 4;} 
> to be treated as a function(not a function pointer). With it 
> being treated as a function, I would expect it to be called 
> with optional parens and type "a" to an int. I would expect auto
>
>       a = &{return 4;};
>
> to type "a" to a function pointer, which makes much more sense 
> to me. But that's not how function literals work right now. 
> Treating {return 4;} as a function(not a function pointer) 
> makes a lot more sense and allows
>
>      alias a = {return 4;};
>
> to work as well, which is simply a function declaration.

Not crazy about your last point, TBH. Personally I really dislike 
function literals being _just_ `{ ... }` and as a matter of 
principle only write `(){...}` when I need one. `{}` to me can 
only mean blocks that are part of the current scope, but they're 
sometimes that and sometimes lambdas, depending on whether they 
had any `return`s and are in a place to be assigned a name or 
immediately called :/

A related thing is having _some way_ to quickly return a value 
from inside an invoked function literal without `return`. Somme 
stuff can't be done in a one-liner and need _two_(ish) lines and 
have to write, say, `{ Type myval, myres; res_by_ref(myval, 
myres); return myres; }()` instead of `{ Type myval, myres; 
res_by_ref(myval, myres); myres }` (expression-oriented) or `(){ 
...; => myres; }()`(hypothetically). Point is, writing `return` 
in the middle of a function and having it return _only_ from a 
lambda breaks the flow, I believe, same as in C++.