Proposal: Improved Type Inference for Generic Instance Creation

Jeremy Manson jeremy.manson at
Sat Feb 28 07:33:01 PST 2009

On Sat, Feb 28, 2009 at 6:35 AM, Neal Gafter <neal at> wrote:
> On Fri, Feb 27, 2009 at 11:54 PM, Jeremy Manson <jeremy.manson at> wrote:
>> Hey Neal,
>> I think you might have missed where I asked for an example where G1
>> and G2 might have different numbers of type parameters or they might
>> have corresponding parameters in a different order.  I'm probably
>> missing a very obvious example, and I'm sure you have an example in
>> mind.
> Sure.  A very simple example would be
> interface A<X,Y> { ... }
> class B<Y,X> implements A<X,Y> { ... }
> Please don't let the use cases drive the design.  Use cases are
> appropriate to test whether a design satisfies its requirements, but
> tuning the design to the use cases results in a writhing mass of
> special cases.  I've written about this category of language-design
> error before <>,
> and the importance you seem to place on this question suggests that is
> the approach you're using.

I understand your concern about this, but I think that perhaps I was a
little unclear about my goals. When I was writing this proposal, I was
deliberately trying to make it limited in scope, but leave room for it
to be expanded for future, more comprehensive type inference solutions
(say, in Java 8 or later).  My feeling was that it was okay if I
missed some of the hard cases, as long as what I was doing covered
more useful cases and left room for the harder ones to be included in
a future JSR.  That's also one of the reasons why I made inference for
wildcards optional -- I thought that we might not have time to get it

>> On Fri, Feb 27, 2009 at 11:33 PM, Neal Gafter <neal at> wrote:
>>> Adding conversions doesn't make type inference work.  Each conversion
>>> that you want to affect type inference has to be accommodated
>>> specifically in the type inference algorithm.
>> I wasn't suggesting that adding conversions would make type inference
>> work.  I was suggesting that the conversion could be done in place of
>> the type inference.
> It can't if you want overload resolution to work.  Overload resolution
> relies on type inference.
> You appear to be taking the approach of adding a new kind of type to
> represent the result of these new kinds of class creation expressions.
>  To complete the work using this approach, you will need to provide
> some evidence (better yet, sketch a proof) that this approach is a
> sound extension of the type system.  I strongly suspect it isn't
> sound.  I think one can prove that it isn't sound by composing your
> new subtype rule with the natural subtype rule for intersection types
> in the context of an invocation of a generic method.

I was doing something a little dodgier than adding a type, and I admit
to not having been sure that it would work.  Basically, I was trying
to add a conversion that doesn't actually convert, but instead changes
the type of the from-expression.

I will go and think about how / if this works with intersection types
and generic method invocation.


More information about the coin-dev mailing list