On Mon, Nov 25, 2019 at 1:21 PM Ville Voutilainen via Lib <lib@lists.isocpp.org> wrote:
On Mon, 25 Nov 2019 at 23:11, Billy O'Neal (VC LIBS) via Lib
<lib@lists.isocpp.org> wrote:
> This was explicitly brought up for review in LWG and if I recall correctly the result was that we were OK with this inconsistency since that feature test macro had already been shipping in implementation(s).

Vague recollections are not worth much to me. This is at

"Discussion about inconsistency of __cpp_lib_array_constexpr vs
Consistency is nice, but not necessary. No consensus to change. "

Granted, those notes aren't worth much to me either. :) They do seem
to indicate that LWG discussed this
very matter. I still don't see a very convincing reason to deviate
from the policy, considering Richard's correct
remark that the existing feature-testing macro can continue to ship.

Given that __cpp_lib_constexpr_algorithm*s* would be new post-Belfast, and __cpp_lib_array_constexpr would have a new *value* post-Belfast, I find it hard to imagine any reason why we cannot use new names for them. Presumably implementations have not already (a) predicted what value these macros would be given in the Belfast meeting, (b) predicted what those macro values would mean, paper-wise, (c) predicted exactly what will be in those papers, (d) implemented all of that including the macro, and (e) shipped that implementation to customers, already? :-)

Any time we bump the number of a macro, I think SG10 has an opportunity to rename the macro, because there cannot exist any user code assuming what the new number means. The only potentially-problematic part would be removing the old macro: deleting __cpp_lib_array_constexpr might break code, but so might deleting __cpp_lib_constexpr_swap_algorithms and we agreed to do that.