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.
