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

Jeremy Manson jeremy.manson at gmail.com
Sat Feb 28 07:54:14 PST 2009

On Sat, Feb 28, 2009 at 7:33 AM, Jeremy Manson <jeremy.manson at gmail.com> wrote:

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:

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-language17.html>, and the importance you seem to place on this question suggests that is the approach you're using. I understand your concern about this, but I think that perhaps I was a little unclear about my goals. When I was writing this proposal, I was deliberately trying to make it limited in scope, but leave room for it to be expanded for future, more comprehensive type inference solutions (say, in Java 8 or later).  My feeling was that it was okay if I missed some of the hard cases, as long as what I was doing covered more useful cases and left room for the harder ones to be included in a future JSR.  That's also one of the reasons why I made inference for wildcards optional -- I thought that we might not have time to get it right.

Also, with regard to changing type parameter number / positions specifically, I didn't really understand the motivation for them until you gave me the example. You need some motivation before including a feature. Now I understand what you mean, although I'm not 100% convinced that it needs to be included in this proposal (for the reason above, as well as still needing to think about it before I am completely convinced it is a good idea).

Jeremy

More information about the coin-dev mailing list