On Friday, 24 January 2014 at 12:25:13 UTC, Dominikus Dittes
Scherkl wrote:
On Friday, 24 January 2014 at 11:43:08 UTC, eles wrote:
On Friday, 24 January 2014 at 10:40:46 UTC, Dominikus Dittes
Scherkl wrote:
On Thursday, 23 January 2014 at 20:35:56 UTC, Andrei
Alexandrescu wrote:
int a = 2_000_000_000;
int b = a + a;
should not generate weird stuff like -294_967_296 (which it
Long discussion about signed/unsigned integer overflows...
But that is a HUGE source of errors, even in really carefully
developed software in safety critical systems!
I think it is well worth a thought to have a safe type in the
language, even if we buy it with a small performance tradeoff.
Especially for the "automatic" type where the programmer has
not spend much time in carefully choosing the types to be used
(e.g. the code above, even with "auto" instead of "int").
--> If I write code fast, without thinking about subtleties
(like e.g. the return type of main() in "hello world") I expect
the compiler to do something sensible (ok, I doesn't expect if
from C, but we're talking about a better language, do we?) and
I don't expect highest performance.
So I would prefer to have save signed types as default and
maybe new types "sbyte", "sshort", "sint" etc if I need the
last bit of performance, but without automatic conversion to
those unsave types.
Using fast signed types with all the over/underflow and other
unsafe stuff is like manual memory management and pointers
instead of GC and slices - useful to have in case you really
need them, but not the default.
On the Rust mailing list, there's recently been discussion about
auto-promotion to BigInt in case of overflow. Maybe that's a
discussion we should be having as well?
