@gassahara @amiloradovsky@functional.cafe the sqrt is another example of horrible interface. There is no such thing as square root, there is no known arithmetic that can compute it, there is no known algebra that works with it. There is a Babylonian method for example which naturally requires an initial guess, and a terminating condition (precision check or number of iterations). This interface cleanly accommodates the sqrt trick, and many other so called optimizations of square root. I don't want you to not be able to tweak the parameters, I want your tweaking to be legible and self documenting.

I don't think integer overflow is a niche problem. It comes up quite often in various contexts in my experience. I went on with multiplication interface, because it applies to addition as well, and I think is a good basis for a generic arithmetic interface (or only acceptable basis).

Generic code is and will be more efficient than specific code, as systems get more complex and the line between hardware and software blurs (especially if we finally have free markets on production of these), most optimization will be done by compliers, as a simple matter of separation of concerns. It is also our only hope at avoiding degenerate hardware/software that is optimized to run old hardware specific code. Generic code must be as expressive as possible, rejecting abstraction that do not properly capture the essence of the algorithms, otherwise it's not generic, it's a mistake.

I wish I could write a this niche library of arithmetic that supports fundamental types, but I can't without breaking the C/C++ standard.