Syntax decision

[Brian Goetz]

And, I think that after a few months, none of us will.  I think the 
initial reaction is "wahh, different!"  Let's see whether we still hate 
it as much as we think in six months.

On 9/28/2011 1:35 PM, Yuval Shavit wrote:
> Fwiw, I don't find () -> e to be all that ugly...
>
> On Wed, Sep 28, 2011 at 11:46 AM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     Yes, there are lots of possible hacks like this, including:
>       - forcing unary inferred-type lambdas to not use parens:
>         x -> e    instead of allowing  (x) -> e
>       - Not allow casting of nilary lambdas without specifying ()
>         (T)() -> e   instead of allowing  (T) -> e
>
>     But all of these introduce irregularities into the syntax, for the sake
>     of supporting an extra case because people find
>
>       () -> e
>
>     to be ugly.  This increases the complexity of the syntax and means there
>     are more special cases to learn.
>
>     With the current approach, there is only one special case:
>       - All lambdas consist of paren-args-paren-arrow-body
>       - For the special case of unary, type-inferred lambdas, you can omit
>     the parens:  x -> x+1
>
>     Turning that into "you *must* omit the parens" means that all users,
>     even those who don't care about the nilary form, must learn another
>     rule.
>
>     Better suggestions?
>
>     On 9/28/2011 11:04 AM, Steven Simpson wrote:
>      > On 28/09/11 15:41, Brian Goetz wrote:
>      >> The nilary syntax is still a thorn.  But the obvious solution
>     outlined
>      >> below -- allow elision of the () -- leads to a syntactic
>     ambiguity.  If
>      >> ->   { statement; } were a valid lambda, then is:
>      >>
>      >>      (identifier) ->   { statement; }
>      >>
>      >> a one-arg lambda with inferred type, or a cast of a nilary lambda?
>      >
>      > What happens if you treat it as an inferred-type unary?  If the
>     author
>      > intended a casted nilary, will he always get compilation
>     failure?[1]  If
>      > so, can he fix his error by adding the empty param list?:
>      >
>      >     (identifier) () ->   { statement; }
>      >
>      > IOW, nilary brackets aren't always optional.
>      >
>      > [1] Hmm, does he get a syntax error or something more obscure?
>      >
>      >
>
>