Proposal: Improved Type Inference for Generic Instance Creation

Jeremy Manson jeremy.manson at
Sat Feb 28 07:54:14 PST 2009

On Sat, Feb 28, 2009 at 7:33 AM, Jeremy Manson <jeremy.manson at> wrote:
> 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
> right.

Also, with regard to changing type parameter number / positions
specifically, I didn't really understand the motivation for them until
you gave me the example.  You need *some* motivation before including
a feature.  Now I understand what you mean, although I'm not 100%
convinced that it needs to be included in this proposal (for the
reason above, as well as still needing to think about it before I am
completely convinced it is a good idea).


More information about the coin-dev mailing list