Reference implementation
Maurizio Cimadamore
Maurizio.Cimadamore at Sun.COM
Thu Oct 29 02:48:32 PDT 2009
Neal Gafter wrote:
> On Wed, Oct 28, 2009 at 1:41 PM, Jonathan Gibbons
> <Jonathan.Gibbons at sun.com>wrote:
>
>
>> In the short term, we think that the current ("simple") approach is the
>> way to go. Long term, we think we will need something like the
>> "full-complex" approach that Maurizio has described. That will address the
>> need for argument inference. However, we do not have the resources to fully
>> investigate that solution at this point.
>>
>>
>
> I don't believe that the full-complex approach is both implementable and
> upward compatible with the simple approach. However, it hasn't been
> specified in any detail, so it isn't possible for a demonstration to be made
> either way.
Neal, the complex-full approach is essentially your approach plus some
magic to make the following work:
Foo<Object> = new Foo<>(1);
That is, a complex approach that takes into account the expected return
type in order not to infer a type which is too specific. Such an
approach would be compatible with the currently implemented simple
approach (in fact, ANY other approach that takes into consideration the
expected return type would be compatible with the simple approach).
I see your point about choosing between usability and language
evolution. To be honest this seems quite a small price to pay compared
to other choices that have been made for Java w.r.t. to language
evolution. To name 3:
1) support for generic cast w/o reification and raw types --> have made
reification nearly impossible
2) wildcards --> despite their usefulness when writing library methods
they have made the type-system undecidable (well we don't have a full
proof yet, but certainly we have bugs)
3) addiction of synthetic types (captured/intersection types) for better
type-inference --> lead to infinite types and, again, makes it really
hard to discuss seriously about reification
In other words I don't think that the current implementation of diamond
should be blamed for putting Java into the corner. As a side-issue
consider also that the complex approach, and any other inference
approach taking into account actual argument types, has the ''drawback''
of inferring captured types as possible instantiation for a generic
type. E.g.
void m(List<?> ls) {
Foo<?> f = new Foo<>(ls.head); //inferred as Foo<#1>, where #1
extends Object
}
Again I don't think that is is particularly good in term of language
evolution - what does it mean to create an instance of a generic type
parameterized with a captured type? What should the runtime semantics of
Foo<#1> be (assuming you have reification) ?
The simple approach is not corner case-free - there are circumstances in
which simple infers an intersection type, e.g. if the class
type-variable has multiple bounds - but it is definitively better than
having to support intersection types AND captured types at the same type.
Maurizio
> I'm afraid that the currently integrated approach really is
> painting us into a corner. The "complex" approach is more clearly upward
> compatible. If there are insufficient resources to fully investigate, the
> conservative solution would be to implement the "complex" approach (or none
> at all).
>
> I find it remarkable that multi-catch was rejected from Coin for veering too
> near the type system (even though it doesn't effect the type system), while
> at the same time decisions about generic type inference are being included
> in Coin even though we lack the resources to fully investigate their
> long-term impact.
>
> -Neal
>
>
More information about the coin-dev
mailing list