Notes on implementing concise calls to constructors with type parameters

[Maurizio Cimadamore]

> 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.

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>.

Maurizio