> On 3 Apr 2025, at 12:15, Tiago Freire <tmiguelf_at_[hidden]> wrote:
>
> I'm not sure I understand your proposal.
> Except for div_wide, all of the proposed functions are well defined, I.e. no matter what arguments you pass there's a definite well-defined answer that the function is expected to return.
>
> The only exception is div_wide, which has a domain of input values that are considered invalid and intentionally left undefined.

I am told that if one uses conditional checks on such types, performance will suffer enough that it is not worth the effort. Also, a performance problem with multi-precision types using heap allocations, though that is used in dynamic languages.

> Even tough x86 is a popular CPU architecture, that does have a dedicated division instruction, most "other" CPUs don't, so in most "other" cases it is going to be implemented as a function proper rather than a CPU instruction.
>
> x86 doesn't throw exceptions, what happens in this case if inputs are outside of the valid domain the CPU traps. Have tested this with major compiler vendors (MSVC, gcc), which although you can catch this with a blank catch clause (...) it doesn't have a type, it's not a real C++ exception, it doesn't work very well with the C++ exception model.

Somehow, one would be able to engage a function that is not executed if there is no overflow, but can be used to shift to a higher precision at need. Possibly, the arithmetic functions might have an extra argument for such a function.

C++ exceptions are also slow. So the use of actual C++ exceptions might be a separate issue.