[patch] 6646584 Compound assignment with Byte, Short and Character

[Rémi Forax]

Alex Buckley a écrit :
> There is already an RFE filed against the spec to allow these compound 
> assignments. Please see http://bugs.sun.com/view_bug.do?bug_id=5009476 
> which I have updated with an evaluation of why it might (or might not) 
> be a good idea.
alex wrote:

>The question is: do you think a compound assignment to a wrapper should behave like a compound assignment to a primitive,
>even if both may lose information ? 

yes

> Alternatively: given that we already have information-losing compound assignments,
>should we allow more? 

no

>Since this issue unquestionably creates developer confusion,
>I have some sympathy with aligning compound primitive and wrapper assignments by expanding casting conversion
>to allow int->Byte/Short/Character.

Sorry, i am confused.
Do you want to expand casting convertion for all conversions or only for 
compound assignment to a wrapper ?

In my opinion, the first JLS allows b+=1, i think retrospectively that it was a mistake.
Now, we have to live with that. Tiger introduces auto-boxing/unboxing, to avoid surprises
and puzzlers, wrappers should behave like primitives as much as possible.

So I am strongly in favor of allowing B+=1  but I am against creating new holes
by allowing int->Byte/Short/Character anywhere.


>
> Alex
> Spec Lead, Java Language & VM
Rémi