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