On Thu, 6 Jun 2024, Jens Gustedt via Liaison wrote:

> Hi,
>
> Am 6. Juni 2024 19:33:30 MESZ schrieb Joseph Myers via Liaison <liaison_at_[hidden]>:
> > On Thu, 6 Jun 2024, Niall Douglas via Liaison wrote:
> >
> > > Would WG14 be open to including into the C standard library WG21
> > > `std::midpoint()` and `std::lerp()` as defined by
> > > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0811r3.html?
> >
> > The operations are plausible, but we'd need an actual C proposal.
> > Presumably, for example, midpoint would actually have separate midpoint,
> > midpointf, midpointl functions for double, float, long double, plus
> > _Decimal32 / _Decimal64 / _Decimal128 functions, plus Annex H functions
> > for _FloatN / _FloatNx / _DecimalN / _DecimalNx, plus a specification of
> > the preferred quantum exponent for decimal types, plus Annex F
>
> I am not sure that we have to reproduce the nightmare that we have now.
> In C23 we introduced interfaces with a similar generality just as
> tg-macros, and that works perfectly fine.

I think stylistic consistency between old and new interfaces is important.

Some interfaces that were introduced only as type-generic macros are, for
example, iseqsig (comparison macro) and issignaling (classification
macro). Those are:

(a) stylistically consistent with previous such interfaces, both in naming
and in being only a macro;

(b) fully determined independent of the rounding mode.

By contrast, existing interfaces analogous to midpoint and lerp are
per-type functions, not macros, and the results of those operations depend
on the rounding modes. Furthermore, the existing analogous interfaces are
functions that are listed in Tables 7.1 and 7.2 as affected by constant
rounding modes. Note that for such functions, suppression of macro
expansion is how to choose to use the dynamic rounding mode in place of
the constant rounding mode - providing them only as macros would thus lose
the ability to call them with the dynamic rounding mode within the scope
of an FENV_ROUND / FENV_DEC_ROUND pragma specifying a constant rounding
mode.

> And then I am chocked that, even if you suppose that we need linker
> interfaces for all the cases, that there would be nothing better to do
> than to violate the user space naming guarantees yet again. Aaron did
> all his work on reserved names for nothing, just that we throw these
> rules over board at the first occasion ?

For many functions, using different naming would result in very ugly
stylistic inconsistency between old and new functions (this is why it
would have been a bad idea to have stdc_exp10 when we already had exp,
exp2 and expm1 in previous standard versions, for example).

You could make an argument for midpoint and lerp being sufficiently
different from existing functions to give them stdc_* names. I'm doubtful
of that difference - I think they fit well with other kinds of basic
manipulation functions such as remainder, fdim, fma - but it's a more
plausible argument than it would have been for exp10 or roundeven, for
example. That would definitely not apply for the other functions I
mentioned - three-argument hypot (call it hypot3, hypot3f, etc.) and
additional <complex.h> functions (for which names are already listed as
(potentially) reserved).

The main point of my message was to enumerate various places that would
need updating in any actual C proposal for new mathematical functions,
such as Annexes F and H and the table of DFP quantum exponents, rather
than to advocate for a particular choice of naming of functions in such a
proposal.

-- 
Joseph S. Myers
josmyers_at_[hidden]