Notes on implementing concise calls to constructors with type parameters

[Ulf Zibis]

Am 15.05.2009 01:11, Neal Gafter schrieb:
> This cannot be an error unless the Java Language Specification 
> requires it to be an error.

So my proposal is to change the JLS in a way, that it requires to be an 
error.
Statement:
    Cell<String> cs = new Cell(1);
should be defined as an error for generic type T as parameter of a 
constructor, if literal/expression is not assignment compatible to the 
substitution of T on the LHS.

>   The language specification does not currently require it to be an error.

Currently yes.

>   I have no idea what change you are proposing to the specification 
> that would result in it being an error.  Without knowing that, I 
> cannot evaluate your proposal.

Sorry, I don't get what you are not understanding. Maybe english 
language problem.

-Ulf


>
> On Thu, May 14, 2009 at 4:07 PM, Ulf Zibis <Ulf.Zibis at gmx.de 
> <mailto:Ulf.Zibis at gmx.de>> wrote:
>
>     Am 15.05.2009 00:56, Neal Gafter schrieb:
>
>         On Thu, May 14, 2009 at 2:31 PM, Ulf Zibis <Ulf.Zibis at gmx.de
>         <mailto:Ulf.Zibis at gmx.de> <mailto:Ulf.Zibis at gmx.de
>         <mailto:Ulf.Zibis at gmx.de>>> wrote:
>
>            So no functionality would break, if this accordingly would be
>            upgraded in the Java Language Specification?
>
>
>         I have no way to tell without knowing what specification
>         change you have in mind.
>
>
>     I mean, to determine
>
>       Cell<String> cs = new Cell(1); //unchecked warning
>     as error from compiler side.
>
>     My guess is, that this problem could be managed by javac option
>     "-source 1.7", to remain compatible, but I'm not sure if there are
>     some reasons against this.
>
>     -Ulf
>
>
>
>
>