> You're proposing an interface with templates. Are you sure they can be
> implemented efficiently inline for all architectures? Shouldn't they be
> out-of-
> line and provide only int, long, and long long support via overloads?
>

I'm not really sure what you mean by that. There is no guarantee that "long
long" or "int" are "efficient" either, and the standard generally doesn't
care about this. The other functions in <numeric> such as saturating
arithmetic or gcd are also templates, and accept any integer type. Whether
that is "efficient" is a QoI issue. I'm just following conventions.


> Paralleling the std::div function, should this return div_t? On some
> architectures, the division instruction already provides the modulus, so
> it
> would be useful to return both at the same time.


To my knowledge, std::div is a historical relic which mostly exists because
the rounding mode of division was unspecified in C, but was truncating for
std::div. There's really no point in using it anymore. Every optimizing
compiler will fuse separate division and remainder operations into one div
instruction.


> In your reference
> implementation, every single std::div implementation is calculating both
> (x/y)
> and (x%y), so it probably won't be too expensive to just return both
> quotient
> and remainder anyway. In any case, given the precedent API that std::div
> poses, it's probably better to follow it for anything whose name starts
> with
> std::div and find another name for quotient-only results.
>

It's only superficially true that the reference implementation *always*
computes the remainder. Many of the functions only need to check if the
remainder is nonzero, which is possibly cheaper. For example, if the
optimizer knows that the dividend is lower than the divisor, there will
always be a remainder (unless it's zero). Also, the remainder still needs
to be adjusted to match the adjustments made to the quotient for the
rounding mode. You're not getting the remainder entirely for free.

Anyhow, I think you're reading too much into std::div. Combined
quotient/remainder functions seem unmotivated to me, and they're not
entirely trivial to implement if you need high QoI instead of just
computing the remainder in terms of the quotient. For a lot of these
functions, the remainder isn't particularly interesting anyway, and you
could just compute it in terms of the quotient if you needed it.

Also note that virtually every C++ resource you will find online calls
these functions div_floor and div_ceil and whatnot. I care much more about
making C++ users happy than being consistent with old junk in the standard.


> I'd also suggest this be proposed to the C standard. There's nothing here
> that
> requires C++ or benefits only C++. C2y may get constexpr functions and,
> even if
> they don't, it would be easy for implementations to provide the std::
> versions
> with constexpr with a suitable if consteval.
>

It would be cool to have this in C too, yeah. Maybe the design on C++ side
should be ironed out first though.


> Finally, why so many options? Do we really need them? Why can't we settle
> for
> the standard ones from the FP environment: nearest (odd/even tie
> breaking),
> towards +Inf, towards -Inf, and towards zero?


At the very least, rounding away from zero should also be a thing. It's
quite common that you'd want to scale down, say, survey data with a max of
[-n, n] points onto a range of [-10, 10], and round either away from zero
or towards zero to not introduce a bias towards one side.

If you map test scores from, say, 0 to 100 onto an even amount of grades
with nearest rounding, it would also make little sense to round to even/odd
rather than consistently to negative infinity, positive infinity, or zero.

In general, any one of the rounding modes is somewhat useful in certain
domains/use cases, and I don't see a benefit to minifying the proposal. Why
should we be limited to a handful of choices inspired by <math.h> design
from 40 years ago? Whether the proposal has 5 functions or 25 makes little
difference in the grand scheme of things. The wording is small, the
implementation is only a few (relatively similar) lines each, and all of
this is simple, numeric, header-only stuff.

The implementation cost for anything to do with floating-point is much
greater, and so different standards and design practices apply.