Even better yet:

	byte b;
	b = -b;		// Deprecation error

WAT????


T

-- 
All men are mortal. Socrates is mortal. Therefore all men are Socrates.

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

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

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)?

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.

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.

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

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.

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.

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