Syntax decision

[Brian Goetz]

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?
>
>