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@lists.isocpp.org>
Date: Sat, Nov 23, 2019 at 9:50 PM
Subject: Re: [isocpp-lib] __cpp_lib_constexpr_algorithm*s*
To: <sg10@lists.isocpp.org>, C++ Library Working Group <lib@lists.isocpp.org>
Cc: Richard Smith <richardsmith@google.com>


On Sat, Nov 23, 2019 at 7:41 PM Richard Smith <richardsmith@google.com> wrote:
Hi SG10,

http://wiki.edg.com/pub/Wg21belfast/StrawPolls/p1902r1.html#constexpr-policy establishes the following policy, specifically calling out <algorithm> as a special case:

"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 <utility>).

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)?

Thanks!
Richard
_______________________________________________
Lib mailing list
Lib@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib
Link to this post: http://lists.isocpp.org/lib/2019/11/14456.php