On Tue, 26 Nov 2019 at 03:15, Casey Carter <[email protected]> wrote: > > On Mon, Nov 25, 2019 at 3:43 PM Ville Voutilainen > <[email protected]> wrote: >> >> On Tue, 26 Nov 2019 at 00:59, Casey Carter <[email protected]> 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. -- SG10 mailing list [email protected] https://lists.isocpp.org/mailman/listinfo.cgi/sg10
