Thread overview
[Issue 9430] New: short and byte implicitly cast to integer with binary arithmetic ops
Jan 31, 2013
stewart
Jan 31, 2013
stewart
Jan 31, 2013
Jonathan M Davis
Jan 31, 2013
stewart
January 31, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9430

           Summary: short and byte implicitly cast to integer with binary
                    arithmetic ops
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: estewh@gmail.com


--- Comment #0 from stewart <estewh@gmail.com> 2013-01-31 14:52:44 EST ---
This fails to compile with the (equivalent) errors shown below:

void main() {
    byte[3] val = [1, 2, 3];
    byte[3] res2;
    res[0] = val[1]+val[2];  // Error A
    res[0] = val[1]-val[2];  // Error A
    res[0] = val[1]/val[2];  // Error A

    byte a1 = 1, a2 = 2;
    byte result = a1+a2;     // Error B
    assert(result == 4);

    result = a1;
    result += a2;    // OK

    res[0] = val[1];
    res[0] += val[2];  // OK
    res[0] = val[1];
    res[0] -= val[2];  // OK
    res[0] = val[1];
    res[0] *= val[2];  // OK
    res[0] = val[1];
    res[0] /= val[2];  // OK
}


Error A: cannot implicitly convert expression (cast(int)val[1UL] +
cast(int)val[2UL] ) of type int to byte.

Error B: cannot implicitly convert expression (cast(int)a1 + cast(int)a2 ) of
type int to byte.


Same is true for short[] arrays. It is true for +, -, *, /

NOTE: It is not the case for +=, -=, *= and /=. These work with byte and short

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
January 31, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9430



--- Comment #1 from stewart <estewh@gmail.com> 2013-01-31 14:55:29 EST ---
additional info:

Compiler:
DMD 2.061 x86_64 Linux
OS: Fedora 18 x86_64
Binary: elf64-x86-64

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
January 31, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9430


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |jmdavisProg@gmx.com
         Resolution|                            |INVALID


--- Comment #2 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-01-30 20:31:37 PST ---
This is expected behavior. It's the same as C/C++ (and probably Java and C#, though I don't remember for sure). Arithmetic operations on integral types result in the largest integral type in the expression or in int if the integral types are smaller than int. And as D requires explicit casts for narrowing conversions (unlike C/C++), a cast is then required to assign to a variable of an integral type smaller than int. So, C/C++ do exactly the same thing as D is doing here, but they allow the implicit cast back to the smaller type, whereas D does not. Unlike C/C++, D _does_ do range propagation such that if it can determine for certain that the result would fit in the smaller type, the cast isn't required, but that generally requires that integer literals be involved.

+=, -=, etc. work because there's no way to do the cast. If you had

a = a + b;

then you could do

a = cast(byte)(a + b);

but there's no place to put the cast in

a += b;

And you're effectively asking for the cast, because the result is being reassigned to a. Whereas with

a = a + b;

the expression on the right hand side (and its type) are evaluated before the assignment takes place, so the fact that you're assigning the result of the expression to a has no effect on how its evaluated or what its type is.

While this behavior might be a bit annoying, it follows from the fact that D requires explicit casts for narrowing conversions, and it generally prevents bugs.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
January 31, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9430



--- Comment #3 from stewart <estewh@gmail.com> 2013-01-31 15:44:14 EST ---
Thanks very much for the explanation, I mistakenly thought D was supposed to perform the implicit cast as well.

I'm glad this is intentional, I much prefer the explicit cast that D requires.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------