hg: lambda/lambda/langtools: Implemented features are:

[Osvaldo Doederlein]

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.

A+
Osvaldo

>
> This is, of course, a discussion for the Coin list.
>
> Alex
>
> 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).
>>
>> A+
>> Osvaldo
>