https://issues.dlang.org/show_bug.cgi?id=17417

anonymous4 <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Give error for signed       |Deprecate signed integer
                   |integer promotions in       |promotions in bitwise
                   |bitwise operations          |operations

--

https://issues.dlang.org/show_bug.cgi?id=17417

uplink.coder@googlemail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |uplink.coder@googlemail.com

--- Comment #1 from uplink.coder@googlemail.com ---
There is a good reason to do the promotion.
The generated machine-code is more efficient in many cases.

Types smaller the uint should only be used for storage, not for operations :)

--

https://issues.dlang.org/show_bug.cgi?id=17417

--- Comment #2 from anonymous4 <dfj1esp02@sneakemail.com> ---
Promotion in bitwise operators makes better sense for unsigned integers, but doesn't make much sense for signed integers, bitwise operators are supposed to act on bit arrays, which signed integers are not. After deprecation the compiler should give an error for signed integer promotions in bitwise operators.

--

https://issues.dlang.org/show_bug.cgi?id=17417

--- Comment #3 from uplink.coder@googlemail.com ---
(In reply to anonymous4 from comment #2)
> Promotion in bitwise operators makes better sense for unsigned integers, but doesn't make much sense for signed integers, bitwise operators are supposed to act on bit arrays, which signed integers are not. After deprecation the compiler should give an error for signed integer promotions in bitwise operators.

There is precedent for for bitwise operations on singed integers as well, such
as right/left shifts.
To save division cost

--

https://issues.dlang.org/show_bug.cgi?id=17417

--- Comment #4 from anonymous4 <dfj1esp02@sneakemail.com> ---
I think it's usually used with int, in which case there will be no promotion. Another thing I can think of is cast(ubyte)(short>>8) which would be a bit more difficult to check that sign extension doesn't affect the result if we would want to allow it.

--

https://issues.dlang.org/show_bug.cgi?id=17417

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |andrei@erdani.com
         Resolution|---                         |WONTFIX

--- Comment #5 from Andrei Alexandrescu <andrei@erdani.com> ---
This is core behavior that we don't plan to change. Value Range Propagation is the way to avoid casts back and forth. Feel free to submit issues related to it, thanks.

--

https://issues.dlang.org/show_bug.cgi?id=17417

anonymous4 <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #6 from anonymous4 <dfj1esp02@sneakemail.com> ---
The issue is not about VRP. Integer promotions don't require casts and happen
without casts (basically inadvertently).
Example: if we have two 16-bit values and want to combine them into a 32-bit
value:
uint v=(s1<<16)|s2;

VRP has nothing to do here.

--

https://issues.dlang.org/show_bug.cgi?id=17417

--- Comment #7 from anonymous4 <dfj1esp02@sneakemail.com> ---
VRP can't do anything here because promotion works according to spec.

--

https://issues.dlang.org/show_bug.cgi?id=17417

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #8 from Andrei Alexandrescu <andrei@erdani.com> ---
Whether or not VRP may help the situation, we won't change the operators. Please do not reopen, thanks.

--