Notes on implementing concise calls to constructors with type parameters
howard.lovatt at iee.org
Thu May 21 19:12:04 PDT 2009
2009/5/22 Joseph D. Darcy <Joe.Darcy at sun.com>:
>> 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
> 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();
auto e = new Ex<String>();
Hopefully you will be able to accommodate one or the other.
More information about the coin-dev