JDK-4655168 : Implied narrowing conversion in compound assignments
  • Type: Enhancement
  • Component: specification
  • Sub-Component: language
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2002-03-20
  • Updated: 2007-09-08
  • Resolved: 2007-09-08
Related Reports
Relates :  
Description

Name: gm110360			Date: 03/19/2002


FULL PRODUCT VERSION :
All versions

A DESCRIPTION OF THE PROBLEM :
I suggest canceling the hidden narrowing casting in the
compound assignments such as +=.

Currently the JLS states:
"A compound assignment expression of the form E1 op = E2 is
equivalent to E1 = (T )((E1) op (E2)), where T is the type
of E1, except that E1 is evaluated only once. Note that the
implied cast to type T may be either an identity conversion
(��5.1.1) or a narrowing primitive conversion (��5.1.3)."

Narrowing casting being an unsafe thing by itself and
requiring a thought each time it?s used, is implicit and
hidden here, which makes it much more dangerous.

There is no other place (IMHO) in Java where compiler
performs a data-wiping casting without the programmer's
knowledge and an explicit approval. Thus this feature is
inconsistent with the strong typing system generally
exhibited by Java and compromises its type safety.

Moreover, most, if not all, Java programming and tutorial
books state that a+=b is equivalent to a=a+b. So if one day
they will become equal nobody will pay attention except
those who will be surprised to find bugs hidden in their
code due to the feature. The negligible minority who used
the feature consciously will have to rewrite it as a=(T)
(a+b), which is a small price for regaining Java type
safety.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
int x = 0;
x += 0.5;

EXPECTED VERSUS ACTUAL BEHAVIOR :
I would expect an error here or at least a warning.

This bug can be reproduced always.
(Review ID: 139922) 
======================================================================

Comments
EVALUATION It's better to keep the cast than drop it. Consider: int x = 0; x = x + 0.5; The second line doesn't compile because binary numeric promotion causes the RHS to have type double, and assignment conversion does not (and should not, for the reasons in the Description!) perform narrowing primitive conversion from double to int. It makes no sense to make x+=0.5 equivalent to x=x+0.5 (i.e. no cast) when x=x+0.5 is illegal. Dropping the cast would make compound operators legal only when x is wider than y in 'x op= y' [1]. Since there are uses of op= in the world which do not fulfil that constraint, we cannot change it now. [1] There are other conditions too, since BNP will often make the RHS into a wide type. For example, even though char is wider than byte, this: char x = 'a'; x += (byte)1; would not be permitted since x = x + (byte)1; is not permitted.
08-09-2007

EVALUATION It's an incompatible change, so I'm reluctant to do it. ###@###.### 2003-01-28
28-01-2003