C++ Logo


Advanced search

[SG10] Fwd: [isocpp-lib] __cpp_lib_constexpr_algorithm*s*

From: Barry Revzin <barry.revzin_at_[hidden]>
Date: Mon, 25 Nov 2019 20:54:25 -0600
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
> 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

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
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib
Link to this post: http://lists.isocpp.org/lib/2019/11/14456.php

Received on 2019-11-25 20:56:58