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

Neal Gafter neal at gafter.com
Sat Feb 28 21:06:04 PST 2009

On Sat, Feb 28, 2009 at 4:04 PM, Jeremy Manson <jeremy.manson at gmail.com> wrote:

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-

If you intend to constrain the relationship between G1 and G2 by the way their type parameters are related, you should add that to the specification.

The way you describe your intent in the specification, it seems as if you're saying that the type "changes" when the conversion is applied. That is unlike anything else in the language. The JLS currently assigns a single type to every expression in the language, statically. Two types are either related by a subtype relationship, or they aren't, and the result shouldn't depend on the order by which subtype tests are done.

Dropping an erased type into type inference may "break" type inference. For example, it may result in erased types in the results of type inference. Given the delicacy of type inference, these things either need to be worked out in detail more formally, of the specification should be based entirely on existing mechanisms. Joe and I have been looking at the latter approach.

I'll be surprised if Joe includes in project Coin any proposals that have substantial outstanding technical issues.

Regards, Neal

More information about the coin-dev mailing list