Proposal: Improved Type Inference for Generic Instance Creation (original) (raw)

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

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

More information about the coin-dev mailing list