On Friday, 24 July 2015 at 21:44:42 UTC, Tofu Ninja wrote:
But the part that I don't think makes sense forauto 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 autoa = &{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 allowsalias 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++.
