On 06/24/2016 06:23 PM, Walter Bright wrote:
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.
These functions are not supposed to be used naïvely.
2. Things become further obfuscated when type aliases are used.
These functions are not supposed to be used naïvely.
3. Mixing signed and unsigned integer types calls which overload?
These functions are not supposed to be used naïvely.
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.
These functions are not supposed to be used naïvely.
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.
Wait, what? std.conv.to much?
> 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.
OK.
2. The overflow count could conceivably itself overflow, thereby masking
the failure in rare cases.
Touché.
> 3. There should be an exponentiation function.
Agreed.
Yay.
Andrei
