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
