Notes on implementing concise calls to constructors with type parameters

[Howard Lovatt]

Hi Joe,

Answers in-line.

2009/5/22 Joseph D. Darcy <Joe.Darcy at sun.com>:

[snip]

>> Yet to a human reader it is obvious that it is type sound. Now
>>
>
> Yes, and as Peter Levart has detailed, the human reader is wrong.

Just a pedantic point. The example I gave is type sound and therefore
an ideal compiler wouldn't reject it. Peter didn't suggest the example
wasn't type sound, he just explained why the compiler has difficulty
with it.

> The compiler  messages are a known shortcoming which are being addressed in
> JDK 7; the messages from current builds are much better and another round of
> message improvements just hit the langtools Mercurial repository.

Glad to hear it - it is not very sexy work but very important.

> We will not be adding a textual substitution algorithm type inferencing
> algorithm in JDK 7; further discussion on this matter is not necessary.

I am not wedded to any particular algorithm or even to type
declarations on the left, but I do hope that what every you decide on
is goes further than the current diamond proposal. I an not a fan of
this proposal because the diamond operator looks like it should be
declaring a raw type and because it only infers the generic parameters
and not the type as well. As you can see from the forum there is
plenty of support for either:

Ex<String> e = new();

or

auto e = new Ex<String>();

Hopefully you will be able to accommodate one or the other.

  -- Howard.