Notes on implementing concise calls to constructors with type parameters

Neal Gafter neal at
Thu May 14 03:55:19 PDT 2009

On Thu, May 14, 2009 at 2:00 AM, Maurizio Cimadamore <
Maurizio.Cimadamore at> 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

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


More information about the coin-dev mailing list