Subject: Fwd: [isocpp-lib] __cpp_lib_constexpr_algorithm*s*
From: Barry Revzin (barry.revzin_at_[hidden])
Date: 2019-11-25 20:54:25
Due to list problems, neither of Richard's emails showed up in the
archives, so I'm just re-forwarding it.
---------- Forwarded message ---------
From: Richard Smith via Lib <lib_at_[hidden]>
Date: Sat, Nov 23, 2019 at 9:50 PM
Subject: Re: [isocpp-lib] __cpp_lib_constexpr_algorithm*s*
To: <sg10_at_[hidden]>, C++ Library Working Group <lib_at_[hidden]
Cc: Richard Smith <richardsmith_at_[hidden]>
On Sat, Nov 23, 2019 at 7:41 PM Richard Smith <richardsmith_at_[hidden]>
> Hi SG10,
> http://wiki.edg.com/pub/Wg21belfast/StrawPolls/p1902r1.html#constexpr-policy establishes
> the following policy, specifically calling out <algorithm> as a special
> "For the library, we will add a specific feature test macros for
> significant, special features. Otherwise, for those cases where we are just
> adding constexpr to more things in the library, we will have a dedicated
> test macro per header and just bump that header-specific macro on each
> change. That macro will be named __cpp_lib_constexpr_HEADER (with the
> exception of a few preexisting macros for array and algorithm which have
> slightly different names)."
> But... we actually don't have a __cpp_lib_constexpr_HEADER macro for
> <algorithm> yet. We *did* have a __cpp_lib_constexpr_swap_algorithms
> macro... until LWG issue 3256, applied by LWG motion 1 in Belfast, removed
> it and added a new macro for algorithms:
> ... with the wrong name. The new macro is called
> __cpp_lib_constexpr_algorithms, not __cpp_lib_constexpr_algorithm.
> Should we rename it again (to remove the "s")? Given that this is a
> brand-new macro, I don't see any reason to deviate from our policy here.
> The proposal for __cpp_lib_constexpr_algorithms is that it covers the
> additions in P0202 and P0879:
> These papers also cover the addition of 'constexpr' to std::swap and
> std::exchange, which are in <utlility>, not <algorithm>. So I think what we
> should do is:
> Remove __cpp_lib_constexpr_algorithms
> Add both __cpp_lib_constexpr_algorithm and __cpp_lib_constexpr_utility,
> defined to 201703L if the relevant parts of P0202 are implemented, and to
> 201806L if the relevant parts of both P0202 and P0879 are implemented.
Sorry, we already added __cpp_lib_constexpr_utility in P1902R1 (with value
201811L), so the proposal here would be to define two new values for it,
and to remove the trailing "s" from the new __cpp_lib_constexpr_algorithms
macro (and change the SD6 description of it to exclude the changes to
Incidentally, that'd leave the only __cpp_lib_array_constexpr deviating
from policy. Why not fix that too? Library vendors can continue to define
the old macro name too (as a conforming extension) if they so wish.
Does that seem right to everyone? Does LWG have a reason to want to deviate
> from SG10 policy here (other than the obvious one that this issue
> resolution simply predates said policy)?
Lib mailing list
Link to this post: http://lists.isocpp.org/lib/2019/11/14456.php
SG10 list run by email@example.com