Proposal: Improved Type Inference for Generic Instance Creation

[Jeremy Manson]

On Sat, Feb 28, 2009 at 6:35 AM, Neal Gafter <neal at gafter.com> wrote:
> On Fri, Feb 27, 2009 at 11:54 PM, Jeremy Manson <jeremy.manson at gmail.com> 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 <http://gafter.blogspot.com/2006/09/failure-of-imagination-in-language_17.html>,
> 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.

>> On Fri, Feb 27, 2009 at 11:33 PM, Neal Gafter <neal at gafter.com> 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.

Jeremy