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

Jeremy Manson jeremy.manson at gmail.com
Sat Feb 28 16:04:02 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:

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've thought about this some more (after a nap :) ). My current position is that I'm not actually introducing a new kind of type. What I am introducing is a hole where a type goes later (when it can be inferred). This needs to be clearer in the proposal (where, on rereading, it does imply I am introducing a type). Given that, I don't think it interferes with the subtype rule for intersection types. You basically apply the inference / rules for overload resolution under the assumption that the type of the actual parameter is an erased type (which does not introduce any constraints, I believe), and then you "drop in" the type arguments to the formal parameter as the type arguments to the actual.

It is reasonably clear to me that my aims were more modest than yours. Some of the things you want to do (like change parameter order) cannot be done without deeper type hackery. I would be interested in pursuing that if we decide that that is what we want as a group, so we should probably have a higher-level discussion about what our goals for this proposal are.

Jeremy

More information about the coin-dev mailing list