Notes on implementing concise calls to constructors with type parameters

[Neal Gafter]

On Thu, May 14, 2009 at 4:43 AM, Maurizio Cimadamore <
Maurizio.Cimadamore at sun.com> wrote:

>
>  Why is it an advantage to do type inference separately and before method
>> (constructor) resolution, when in every other context type inference is
>> done
>> *as part of *overload resolution?  I would think that it makes more sense
>> to
>> be consistent with the way things are already done.
>>
>>
>>
> I guess that what worries me is that with your approach you are not just
> inferring a method signature given a site - you are also inferring the
> site's type, which by 15.12.2 is supposed to be fully known when overload
> resolution is applied. Quoting from the beginning of 15.12.2:
>
> "The second step searches the type determined in the previous step for
> member methods".
>
> With my approach, when you reach 15.12.2 (e.g. from 15.9.3 - choosing the
> constructor and its arguments) you already have a type to search for member
> constructors (because I would apply return-type inference during 15.9.1).
> With your approach such type is simply unknown (only the erased type can be
> known) - and it might depend on what you discover later on when performing
> overload resolution.


15.9.1 doesn't need, refer to, or use the class's type parameters.  Neither
does 15.9.2 care about the type parameters.  They aren't used until 15.9.3,
and that defers to the rules for method invocation (15.12) for inference.
That's precisely where I suggest the fix belongs - in the *way* that it
defers to 15.12.

This leads to subtle differences in e.g. how errors are handled; e.g. if you
> do:
>
> Foo<String> fs = Foo<>(1);
>
> I would expect the compiler to complain because init(Integer) cannot be
> found inside Foo<String>. With your approach things do differently: first
> the compiler infers that Foo<Integer> is created, then it reports an error
> in the assignment, as Foo<Integer> cannot be assigned to Foo<String>. Again,
> with my approach what you get is essentially the same error you would have
> get by replacing Foo<> with Foo<String>.


I have confidence in your ability to write clear diagnostics that would
apply to the assignment context as well as other contexts.