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 <[email protected]> Date: Sat, Nov 23, 2019 at 9:50 PM Subject: Re: [isocpp-lib] __cpp_lib_constexpr_algorithm*s* To: <[email protected]>, C++ Library Working Group <[email protected] > Cc: Richard Smith <[email protected]> On Sat, Nov 23, 2019 at 7:41 PM Richard Smith <[email protected]> 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: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1917r0.html#3256 > ... 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: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0202r3.html > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0879r0.html > > 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 [email protected] Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib Link to this post: http://lists.isocpp.org/lib/2019/11/14456.php
-- SG10 mailing list [email protected] https://lists.isocpp.org/mailman/listinfo.cgi/sg10
