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

Neal Gafter neal at gafter.com
Sat Feb 28 06:35:24 PST 2009

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.

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.

More information about the coin-dev mailing list