A syntax option (function types versus arrays)

[Joshua Bloch]

Peter,

Ooops, sorry; I thought the last message I answered was your response to my
query.

On Tue, Mar 2, 2010 at 3:41 AM, Peter Levart <peter.levart at marand.si> wrote:

> On Tuesday 02 March 2010 08:58:28 Joshua Bloch wrote:
> > Peter,
> >
> > On Mon, Mar 1, 2010 at 11:49 PM, Peter Levart <peter.levart at marand.si
> >wrote:
> >
> > > I think we don't need statement lambdas if we allow expression to be
> > > preceeded by statements (like in block expression of CfJ0.6b):
> > >
> > > Lambda:
> > >  '(' FormalParameters_opt '->' Statements_opt Expression ')'
> > >
> > > for void lambdas "void" keyword could be defined as expression of type
> > > void:
> > >
> > > (->void) lambda = (-> System.out.println("Hello!"); void);
> > >
> >
> > Why do you like this better than the current proposal?
> >
> >     Josh
> >
>
> Regarding function types syntax I don't really have a preference to the
> order of (parameter types, return type, throws types) but I think that a
> syntax that composes well (nests) is better. In this regard the current
> proposal is not the best of all alternatives.
>

I agree that it would be nice if we had something that nests better, and I'm
totally open to suggestion.  But this alternative comes with many downsides:
surrounding a type in parens might appear tempting, but it really looks like
a cast to current-day Java programmers.  As per my previous e-mail, I'm all
about designing a facility that is maximally readable, familiar, and
non-threatening to current-day Java programmers.

>
>

>
> Regarding preference to expression lambdas, I think they provide a way to
> avoid defining the meaning of "return" at present time. The 1st release of
> lambdas in JDK7 could simply disallow "return". Experience gathered from the
> milions of Java developers in comming years would help shape a decision of
> what to do with "return" (be it local or transparent) for the next release
> in JDK8 which could add statement lambdas as well.
>

I think you can probably guess how I feel about this argument. I believe
that preserving the meaning of return to return a value from the
function-object invocation (as per current-day use of SAM types) is the way
to go. If, in a future release we elect support non-local returns, it will
probably require a new keyword to clearly distinguish local and non-local
returns.  We should cross that bridge when/if we come to it, but in the
meantime, it's our job to make the best possible lambda syntax and
semantics, as per the charter of this project.

          Josh