On Tue, 26 Nov 2019 at 03:15, Casey Carter <cartec69_at_[hidden]> wrote:
>
> On Mon, Nov 25, 2019 at 3:43 PM Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>>
>> On Tue, 26 Nov 2019 at 00:59, Casey Carter <cartec69_at_[hidden]> wrote:
>> >
>> > Shipping multiple feature-test macros for the same feature is trivially simple for implementors. Requiring users to check multiple feature-test macros to detect a single feature - the detection needs to work both in old and new implementations - seems hostile.
>>
>> Fully agreed, but I don't see anyone suggesting such hostilities. You
>> can continue shipping the old spellings,
>> and we all can, and we can still do the policy-fixes in the standard,
>> and no user will be hurt the slightest.
>> That's what I mean by not seeing a convincing argument to deviate from
>> the policy; renaming
>> __cpp_lib_array_constexpr doesn't in any way prevent you from
>> continuing to ship that macro spelling.
>
>
> Say an implementation has shipped __cpp_lib_meow, and WG21 chooses to rename __cpp_lib_meow to __cpp_lib_woof. The implementation continues to ship __cpp_lib_meow, and adds __cpp_lib_woof. This takes five minutes of work, the implementor is not bothered.
>
> Users want to use this feature everywhere it's available. Since there are implementations in the wild that only define __cpp_lib_meow, and the standard only requires implementations to define __cpp_lib_woof, such users must check both __cpp_lib_meow and __cpp_lib_woof.

While that is remotely plausible to me, would you consider it
plausible that implementations would provide __cpp_lib_meow
even if the standard doesn't require it? I agree with your general
notion that we shouldn't churn the macros without
good reasons, and it's highly questionable whether policy-consistency
is worth this particular bit of churn. But hopefully
our implementation vendors would do the right thing in case of such churn.