core.checkedint

[Walter Bright via Digitalmars-d]

On 6/24/2016 9:56 AM, Andrei Alexandrescu wrote:
> 1. No need for different names (addu/adds) etc., overloading should take care of
> it (simplifies caller code). Right now the API is an odd mix of overloading and
> distinct names.

The reason for the different names is:

1. Integral promotion rules will affect which overload is selected, when the 
argument type is not an exact match. Few programmers have an exact understanding 
of integral promotion rules.

2. Things become further obfuscated when type aliases are used.

3. Mixing signed and unsigned integer types calls which overload?

4. People who use core.checkedint want pedantically correct code. Being 
absolutely sure what operation is being done is part of that. Using different 
names makes it trivially inspectable.

5. It is a design mistake to make overloads with the same name have different 
implementations. Arguably, in this context, a signed overflow is different from 
an unsigned overflow, and so should properly be a different name.



 > 2. The overflow flag should be an integral, not a bool, so you get to count 
how many overflows there were. This is minor but has no extra cost on the happy 
case.

I see no value in this beyond amusement value, and a potential bug:

1. One operation in a sequence that overflows will make subsequent operations 
meaningless, and will likely even cause more overflows. Sticky error flags are 
used in floating point, and I've never heard any desire for nor use case for counts.

2. The overflow count could conceivably itself overflow, thereby masking the 
failure in rare cases.



 > 3. There should be an exponentiation function.

Agreed.