Syntax decision

[Robert Field]

Regularity in language design... good.
Regularity in new language features... very good.
Saving a couple characters... not very important.

-Robert

On 9/28/11 8:46 AM, Brian Goetz 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?
>>
>>