Annoyance with new integer promotion deprecations

Guillaume Piolat notthat at email.com
Sun Feb 18 19:21:29 UTC 2018


On Sunday, 18 February 2018 at 13:36:28 UTC, Dmitry Olshansky 
wrote:
> On Sunday, 18 February 2018 at 01:09:57 UTC, Manu wrote:
>> On 5 February 2018 at 11:22, H. S. Teoh via Digitalmars-d < 
>> digitalmars-d at puremagic.com> wrote:
>>
>>> Code:
>>>
>>>         struct S {
>>>                 byte[2] x;
>>>         }
>>>         void main() {
>>>                 S s, t;
>>>                 s.x = [ 1, -1 ];                // OK
>>>                 t.x = [ -s.x[0], -s.x[1] ];     // NG (line 7)
>>>         }
>>>
>>>
>>> Compiler says:
>>>         /tmp/test.d(7): Deprecation: integral promotion not 
>>> done for
>>> `-s.x[0]`, use '-transition=intpromote' switch or 
>>> `-cast(int)(s.x[0])`
>>>         /tmp/test.d(7): Deprecation: integral promotion not 
>>> done for
>>> `-s.x[1]`, use '-transition=intpromote' switch or 
>>> `-cast(int)(s.x[1])`
>>>
>>>
>>> Why should I need to explicitly cast to int only to reassign 
>>> it back to byte?!  This is ridiculous.
>>
>>
>> Seriously, WTF is going on here?

D used to not promote integer like C in the case of -short, 
-byte, ~ubyte etc. Which is a strange discrepancy as all other 
integer arithmetic are the same.

I'm surprised by the number of complaints, what do you prefer:
- explain until the end of times that D has the same integer 
promotion that C, except for one edge case with unary ops and 
smaller integers? and have translated C code have subtle bugs.
- add a cast here and there for some years



More information about the Digitalmars-d mailing list