Notes on implementing concise calls to constructors with type parameters

[Neal Gafter]

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

> Let me start by saying that all the examples I found in this thread
> exploits inference from the return type.


If you're looking for an example, given

*class X<T> {*
*  public X(T t) { ... }*
*}*

*void f(X<String> xs) ...*

the code

*f(new X<>("foo"))*

works with my formulation of inference, and doesn't with yours.  See also
http://gafter.blogspot.com/2006/09/failure-of-imagination-in-language_17.html

But there's a more compelling reason for which I think my solution is
> pragmatically a good idea: it doesn't alter the way in which method
> (constructor) resolution is performed. That is, after the the site has been
> inferred (from the assignment context) standard method resolution can be
> applied to resolve the constructor to be called in a straightforward way.


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.


> The second advantage is that the inferred type is always somehow mandated
> by the declared type which, given the fact that Java is a strongly typed
> language I consider it to be a good side-effect


Yes, assuming the "diamond" construct is only to be used on the
right-hand-side of an assignment.  But I think it's wrong to make language
constructs non-orthogonal.


> Regarding the fact that ForAll is not present in the JLS - I totally agree
> - they are not part of the JLS whatsoever. In fact this is an
> 'implementation' strategy. The JLS should find an alternate way to specify
> the behavior of the diamond notation - but it doesn't seem - it should
> simply reformulate 15.12.2.8 so that it can be applied to class type
> variables as well as to method type variables.


Um, that's the section on method (constructor) overload resolution.  That's
what I was proposing, however, if I understand what you're suggesting, it
would be done separately and preceding overload resolution.  It would
therefore require a separate new section to specify the desired behavior.

Cheers,
Neal