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