Proposal: Improved Type Inference for Generic Instance Creation

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