core.checkedint
Andrei Alexandrescu via Digitalmars-d
digitalmars-d at puremagic.com
Fri Jun 24 15:29:55 PDT 2016
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
More information about the Digitalmars-d
mailing list