symmetric signed types

[Meta]

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?