<math.h> declare ::lerp?Section: 17.14.7 [support.c.headers.other] Status: C++23 Submitter: Jiang An Opened: 2022-09-17 Last modified: 2023-11-22
Priority: Not Prioritized
View other active issues in [support.c.headers.other].
View all other issues in [support.c.headers.other].
View all issues with C++23 status.
Discussion:
According to 17.14.7 [support.c.headers.other]/1, <math.h> is required to
provide ::lerp, despite that it is a C++-only component. In P0811R3, neither
<math.h> nor C compatibility is mentioned, so it seems unintended not to list
lerp as an exception in 17.14.7 [support.c.headers.other].
::lerp in
<math.h> but not in <cmath>, while MSVC STL and libc++ don't provide
::lerp in <math.h> or <cmath> at all.
I'm not sure whether this should be considered together with LWG 3484.
Since nullptr_t has become a part of the C standard library as of C23
(see WG14-N3042 and
WG14-N3048),
I believe we should keep providing ::nullptr_t in <stddef.h>.
[2022-10-12; Reflector poll]
Set status to Tentatively Ready after six votes in favour during reflector poll.
[2022-11-12 Approved at November 2022 meeting in Kona. Status changed: Voting → WP.]
Proposed resolution:
This wording is relative to N4917.
Modify 17.14.7 [support.c.headers.other] as indicated:
-1- Every C header other than
<complex.h>(17.14.2 [complex.h.syn]),<iso646.h>(17.14.3 [iso646.h.syn]),<stdalign.h>(17.14.4 [stdalign.h.syn]),<stdatomic.h>(32.5.12 [stdatomic.h.syn]),<stdbool.h>(17.14.5 [stdbool.h.syn]), and<tgmath.h>(17.14.6 [tgmath.h.syn]), each of which has a name of the form<name.h>, behaves as if each name placed in the standard library namespace by the corresponding<cname>header is placed within the global namespace scope, except for the functions described in 29.7.6 [sf.cmath], thestd::lerpfunction overloads (29.7.4 [c.math.lerp]), the declaration ofstd::byte(17.2.1 [cstddef.syn]), and the functions and function templates described in 17.2.5 [support.types.byteops]. […]