On Mon, Nov 25, 2019 at 1:21 PM Ville Voutilainen via Lib <
lib_at_[hidden]> wrote:

> On Mon, 25 Nov 2019 at 23:11, Billy O'Neal (VC LIBS) via Lib
> <lib_at_[hidden]> 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
> http://wiki.edg.com/bin/view/Wg21belfast/LWGThursdayAfternoon
>
> "Discussion about inconsistency of __cpp_lib_array_constexpr vs
> __cpp_lib_constexpr_*header*
> 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.