February 05, 2018 Re: Annoyance with new integer promotion deprecations | ||||
---|---|---|---|---|
| ||||
Even better yet:
byte b;
b = -b; // Deprecation error
WAT????
T
--
All men are mortal. Socrates is mortal. Therefore all men are Socrates.
|
February 05, 2018 Re: Annoyance with new integer promotion deprecations | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 2/5/18 2:30 PM, H. S. Teoh wrote:
> Even better yet:
>
> byte b;
> b = -b; // Deprecation error
>
> WAT????
In the future, -b will be typed as an int, so you can't reassign it to b. You can see this today with -transition=intpomote:
Error: cannot implicitly convert expression -cast(int)b of type int to byte
-Steve
|
February 05, 2018 Re: Annoyance with new integer promotion deprecations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Mon, Feb 05, 2018 at 03:23:20PM -0500, Steven Schveighoffer via Digitalmars-d wrote: > On 2/5/18 2:30 PM, H. S. Teoh wrote: > > Even better yet: > > > > byte b; > > b = -b; // Deprecation error > > > > WAT???? > > In the future, -b will be typed as an int, so you can't reassign it to b. You can see this today with -transition=intpomote: > > Error: cannot implicitly convert expression -cast(int)b of type int to > byte [...] Honestly, this just makes narrow int types basically useless when it comes to any arithmetic at all. Sticking to C promotion rules is one of the scourges that continue to plague D; another example is char -> byte confusion no thanks to C traditions: int f(dchar ch) { return 1; } int f(byte i) { return 2; } void main() { pragma(msg, f('a')); pragma(msg, f(1)); } Exercise for reader: guess compiler output. T -- Trying to define yourself is like trying to bite your own teeth. -- Alan Watts |
February 05, 2018 Re: Annoyance with new integer promotion deprecations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | Ouch. I guess "the real WTF" is that 2's complement leads to supporting one value that cannot be negated. But still, I thought we had value range propagation rules to avoid this sort of nonsense when possible (such as the example above)? |
February 05, 2018 Re: Annoyance with new integer promotion deprecations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | On Mon, Feb 05, 2018 at 09:20:16PM +0000, Nick Sabalausky via Digitalmars-d wrote: > Ouch. I guess "the real WTF" is that 2's complement leads to supporting one value that cannot be negated. By that logic, we should issue the same warning for negating ints, but we don't. > But still, I thought we had value range propagation rules to avoid this sort of nonsense when possible (such as the example above)? VRP doesn't help when the code doesn't have compile-time known values, such as in the non-reduced code my example snippet was reduced from. T -- There are two ways to write error-free programs; only the third one works. |
February 05, 2018 Re: Annoyance with new integer promotion deprecations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | On 2/5/2018 1:20 PM, Nick Sabalausky wrote:
> Ouch. I guess "the real WTF" is that 2's complement leads to supporting one value that cannot be negated. But still, I thought we had value range propagation rules to avoid this sort of nonsense when possible (such as the example above)?
The real bug is that VRP should allow this particular case.
|
February 05, 2018 Re: Annoyance with new integer promotion deprecations | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On Monday, 5 February 2018 at 21:21:47 UTC, H. S. Teoh wrote:
> On Mon, Feb 05, 2018 at 09:20:16PM +0000, Nick Sabalausky via Digitalmars-d wrote:
>> But still, I thought we had value range propagation rules to avoid this sort of nonsense when possible (such as the example above)?
>
> VRP doesn't help when the code doesn't have compile-time known values, such as in the non-reduced code my example snippet was reduced from.
If you were negating a byte, the code does have compile-time known values, since there's a limit to what you can stuff into a byte. If you weren't, the warning is warranted. I will admit the case of -(-128) could throw it off, though.
--
Simen
|
February 05, 2018 Re: Annoyance with new integer promotion deprecations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Monday, 5 February 2018 at 21:25:41 UTC, Walter Bright wrote:
> The real bug is that VRP should allow this particular case.
No, because of the byte.min case after promotion to int actually loses information.
But the promotion to int suuuuuuucks. I gave this a lot of thought a few months ago... but wrote it in irc and forgot to copy lol.
The jist of it was to make int math work kinda like float math. Where everything is promoted to the largest type in the expression and if truncation happens, so be it.
int a = 1;
int b = 2;
float f = 1/2; // f == 0, we know this and are ok with it
byte a = 127;
byte b = 1;
byte c = a + b; // this should just wrap and assign!
Of course it is slightly different than C. C, the ruiner of all good things.
|
February 05, 2018 Re: Annoyance with new integer promotion deprecations | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 2/5/2018 12:45 PM, H. S. Teoh wrote: > Sticking to C promotion rules is one of the scourges that continue to > plague D; It's necessary. Working C expressions cannot be converted to D while introducing subtle changes in behavior. > another example is char -> byte confusion no thanks to C > traditions: > > int f(dchar ch) { return 1; } > int f(byte i) { return 2; } > void main() { > pragma(msg, f('a')); > pragma(msg, f(1)); > } > > Exercise for reader: guess compiler output. 'a' and 1 do not match dchar or byte exactly, and require implicit conversions. D doesn't have the C++ notion of "better" implicit conversions for function arguments, instead it uses the "leastAsSpecialized" C++ notion used for template matching, which is better. The idea is a byte can be implicitly converted to a dchar, but not the other way around. Hence, f(byte) is selected as being the "most specialized" match. |
February 05, 2018 Re: Annoyance with new integer promotion deprecations | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 2/5/18 3:45 PM, H. S. Teoh wrote: > On Mon, Feb 05, 2018 at 03:23:20PM -0500, Steven Schveighoffer via Digitalmars-d wrote: >> On 2/5/18 2:30 PM, H. S. Teoh wrote: >>> Even better yet: >>> >>> byte b; >>> b = -b; // Deprecation error >>> >>> WAT???? >> >> In the future, -b will be typed as an int, so you can't reassign it to >> b. You can see this today with -transition=intpomote: >> >> Error: cannot implicitly convert expression -cast(int)b of type int to >> byte > [...] > > Honestly, this just makes narrow int types basically useless when it > comes to any arithmetic at all. They already are: b = b + 1; // error. But I can't see why there is controversy over negation of byte turning into an int. I can't see why anyone would expect: int x = -b; when b is -128, to set x to -128. The integer promotion makes complete sense to me. > Sticking to C promotion rules is one of the scourges that continue to > plague D; C promotion rules came along with the feature of assigning the result back to a byte. D got rid of that "convenience", and I think it was a good decision. I hardly ever finding myself regretting the compiler telling me that I'm about to throw away information. > another example is char -> byte confusion no thanks to C > traditions: > > int f(dchar ch) { return 1; } > int f(byte i) { return 2; } > void main() { > pragma(msg, f('a')); > pragma(msg, f(1)); > } > > Exercise for reader: guess compiler output. char and byte should not ever mix, IMO. char and dchar should not ever mix either. There have been some nasty bugs in phobos due to the fact that char auto-promotes to dchar. -Steve |
Copyright © 1999-2021 by the D Language Foundation