hg: lambda/lambda/langtools: Implemented features are:
alex.buckley at oracle.com
Fri Jul 30 12:30:54 PDT 2010
In the context of a catch block, one would like to treat a disjunctive
type consistently, regardless of how many constituent types it has. Foo
is a disjunctive type of one type, Foo. Foo|Bar is a disjunctive type of
two types, Foo and Bar. In both cases, no | is required after the last
element type in the disjunctive type.
On 7/30/2010 12:25 PM, Osvaldo Doederlein wrote:
> 2010/7/30 Alex Buckley <alex.buckley at oracle.com>:
>> "catch (Foo x)" names a disjunctive type - albeit not a very interesting one
>> - and it would not be backward compatible to ban assignment to x.
> This is not really true; the current language doesn't allow a
> disjunctive type here, the catch's parameter is a simple
> FormalParameter. Any Java7-valid try/catch block that contains a
> CatchFormalParameter that is really a disjunctive type, is not valid
> Java6 code, so there's no source-level compatibility issue from the
> POV of existing code.
> On the other hand, in this special case maybe we're better off with
> just effectively-final - to not confuse the user, and not create
> puzzlers when people upgrade old code to Java7, changing something in
> a try/catch so an existing catch parameter becomes disjunctive, and an
> existing assignment inside the catch becomes illegal.
>> This is, of course, a discussion for the Coin list.
>> On 7/30/2010 11:53 AM, Osvaldo Doederlein wrote:
>>> One possible approach is: make disjunctive types not only eligible for
>>> effectively-final analysis, but _obligatory_ final. Any attempt to
>>> reassign results in error, and that's it. You're doing that on new
>>> syntax and typing features, so there's no legacy or backwards-compat
>>> issues. The user could still put an explicit 'final', that would be
>>> redundant. Not perfect, but there is plenty precedent in Java for this
>>> kind of redundancy and for qualifiers that are needed in some contexts
>>> but default/obligatory (e.g. 'public' for interface members, or
>>> 'final' itself for private methods).
More information about the lambda-dev