symmetric signed types

[Andrei Alexandrescu]

On 1/24/14 2:40 AM, Dominikus Dittes Scherkl wrote:
> On Thursday, 23 January 2014 at 20:35:56 UTC, Andrei Alexandrescu wrote:
>>> byte a = -128;
>>> auto b = -a;
>>>
>>> What type should b get? (of course "byte" but the value doesn't fit!)
>>
>> The type will be int.
> Ah, ok. Of course the small types always become int.
> But the problem would be the same with
>
> long a = long.min;
> auto b = -a;
>
> does this return ulong (which could hold the correct result) or long
> (and a wrong result)?

long

>>> integral types still suffer the same old flaws.
>>
>> There are quite a few improvements for integrals, too, most
>> importantly of the kind that don't exact a speed penalty.
> I can understand that speed is critical for unsigned types but for me
> the main benefit of signed types is their "ease of use" - like in the
> "hello world" program it should be easy to do it right and work "out of
> the box". Errors like
>
> int a = 2_000_000_000;
> int b = a + a;
>
> should not generate weird stuff like -294_967_296 (which it actually
> does) but better produce NaN to indicate that the result is not in the
> valid range or "int".
> For addition that may be not to complicated to handle, but for
> multiplication? There it would be very nice (and fast!!) to have an
> implenetation that checks the carry and set the result to NaN if carry
> is not 0. At the moment doing so requires the use of inline assembler -
> not realy a newbi-thing to do...

There's no NaN for integrals.

I initially protested a number of things about the way D's integral 
expressions are handled. For example I found it ridiculous that unary 
"-" for uint returns uint. Walter talked me into accepting the C-style 
rules and improving them with value range propagation.


Andrei