Proposal: Improved Type Inference for Generic Instance Creation

[Neal Gafter]

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