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

[Alex Buckley]

Hi Rémi,

I've updated the evaluation of 5009476 to propose changing the 
definition of compound assignment in some cases, rather than a global 
change in casting conversion. This will be visible on bugs.sun.com 
within 24 hours, I guess. Please direct further comments about the JLS 
changes to the bugs.sun.com page, rather than compiler-dev.

Alex

Rémi Forax wrote:
> 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