Reference implementation

[Neal Gafter]

On Thu, Oct 29, 2009 at 2:48 AM, Maurizio Cimadamore <
Maurizio.Cimadamore at sun.com> wrote:

>  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).
>

Are you telling me that you're confident that such "magic" can be specified,
and implemented, and retrofitted onto the implementation of generic method
invocations and argument contexts, without any deep issues?  If so, I'm
satisfied.


> 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:
>

I've never bought arguments of the form "things are bad now, so there's no
problem making them worse."

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) ?
>

This is the same question as *existing *type inference for generic methods,
and I would expect the answer to be the same.  Captured types represent
types that, under reification, are available at runtime.  I would expect
#1's type to be taken from the element type of the incoming list.  I suspect
that's naive.  But I also expect (and hope) that inference in argument
contexts is a much more likely and imminent future extension than
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.
>

Given that generic method type inference already does all that, I don't see
that you've simplified anything.

-Neal