Reference implementation

Neal Gafter neal at
Wed Oct 28 11:13:58 PDT 2009

On Wed, Oct 28, 2009 at 10:56 AM, Maurizio Cimadamore <
Maurizio.Cimadamore at> wrote:

> Neal Gafter wrote:
>> Maurizio-
>> Here's my concern: Quoting from
>> inference proceeds in two steps, in this order:
>>   1. inference from actual vs. formal arguments (see JLS
>>   2. inference from return type vs. expected type (see JLS
>> For consistency, any future extension of inference to argument contexts
>> should also proceed in this order - in fact, must proceed in this order
>> because overload resolution depends on the results of the first step, and
>> the results of overload resolution are required to apply the second step.
> Hi Neal
> When you say that overload resolution depends on the result of the first
> step, I guess you refer to the fact that both, and
> refer to Well this is not much of a concern - that
> inference step can be replaced by a full-inference step (round 1 followed by
> round 2) where the expected type is unspecified.

Isn't that basically what is done today?  That is, the parameter type is
ignored ("unspecified") when performing type inference on a method
invocation in an argument context.  That is exactly the issue I'm hoping
will be fixed in a future extension: the method's (expected) parameter type
*should* play a part in the second phase.

Moreover, we think that it is very important to be able to refactor code
> like:
> class Foo<X> {
>   Foo(X x) {...}
> }
> Foo<Object> fo = new Foo<Object>(1);
> with your proposed approach the above code will give an error (see
> statistics and results in [1]).

I see that you conclude, based on those statistics, that "No approach looks
noticeably better than the other."  Your main reason for preferring the
simple approach appears to be that inference in argument positions isn't
done, so few benefits accrue to the more complex approach.  However, I would
hope that consideration of future language evolution - that is, argument
inference might be desirable *in the future* - to be a deciding factor.


More information about the coin-dev mailing list