Date: Thu, 6 Jun 2024 17:33:30 +0000 (UTC)
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
specification of special cases (do midpoint(-Inf, Inf) and midpoint(Inf,
-Inf) return NaN with "invalid" raised, for example? is this an operation
required to be correctly rounded for the current rounding direction or
would that be a separate reserved cr_midpoint name?) - and likewise for
lerp. And any midpoint operations for integer types would go in some
header separate from <math.h>. And if supported for complex types, that
would be in <complex.h>.
If considering mathematical operations from C++ for possible addition to
C, consider also the three-argument version of hypot, and the complex
version of log10 (I'm not actually sure what the use is for complex log10,
but it's in C++, the name clog10 is reserved in C and it's been
implemented for a very long time in glibc). More generally adding the
reserved <complex.h> names as actual functions in C was suggested in
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1704.pdf but C wasn't
open for new features at the time and no proposal with concrete language
appeared while C was open for new features for C23 (also, for many of the
functions there may be a lack of implementation experience or information
about implementation difficulties).
> 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
specification of special cases (do midpoint(-Inf, Inf) and midpoint(Inf,
-Inf) return NaN with "invalid" raised, for example? is this an operation
required to be correctly rounded for the current rounding direction or
would that be a separate reserved cr_midpoint name?) - and likewise for
lerp. And any midpoint operations for integer types would go in some
header separate from <math.h>. And if supported for complex types, that
would be in <complex.h>.
If considering mathematical operations from C++ for possible addition to
C, consider also the three-argument version of hypot, and the complex
version of log10 (I'm not actually sure what the use is for complex log10,
but it's in C++, the name clog10 is reserved in C and it's been
implemented for a very long time in glibc). More generally adding the
reserved <complex.h> names as actual functions in C was suggested in
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1704.pdf but C wasn't
open for new features at the time and no proposal with concrete language
appeared while C was open for new features for C23 (also, for many of the
functions there may be a lack of implementation experience or information
about implementation difficulties).
-- Joseph S. Myers josmyers_at_[hidden]
Received on 2024-06-06 17:33:50