Syntax decision

[Zhong Yu]

On Fri, Sep 30, 2011 at 5:04 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> On 9/30/11 2:53 AM, Zhong Yu wrote:
>>
>> After even longer stare, ()->  looks fine to me; it fades in the
>> background.
>
> I think this is an important point, one that Brian Goetz has made a couple
> times. A large component of syntax like/dislike is what one is used to. I
> had a similar experience when I updated the lambda prototypes to the new
> syntax:
>
> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d9e4e3c106a7
>
> Initially I liked the #{...} syntax and I was opposed to the C#/Scala style
> syntax when it was proposed. But after having worked with the new style
> syntax for just a couple hours, I got used to it. Yes, there are weird
> things about it, but there are weird things about any syntax.

Arguably Java method declaration syntax is weird too:
    name(args){body}
for anyone new to programming. But the syntax has been in mainstream
for 4 decades, so everybody is accustomed to it. That's why I don't
really understand why the strawman syntax, closest to method
declaration, is killed; I read the archive and couldn't find any
objection to it. (I have no intention to argue about syntax, just
curious to learn what's wrong with strawman syntax; ignore me if you
would)

- Zhong Yu

> At this point the #{...} syntax looks old and clunky. Another thing I do not
> miss about the old syntax is that #{ -> expr; } was a statement whereas #{
> -> stmt } was an expression. A missing or extra semicolon could even change
> overload resolution! The new syntax uses { } to distinguish statement
> lambdas, which is perfectly sensible to me.
>
> Using the new syntax, I went through several phases of using extra
> parentheses in order to highlight the lambda, but I eventually pulled them
> all out. You can see the results in the code: there are very few places with
> parentheses where they aren't required. It's a bit unfortunate that the
> nilary lambda requires an empty pair of parens, but (as others have noted)
> making them optional seems to introduce a bunch of problems and special
> cases, and having them isn't really all that bad, so why not just live with
> them.
>
> s'marks
>