Subject: Re: [isocpp-lib] [EXTERNAL] __cpp_lib_constexpr_algorithm*s*
From: Casey Carter (cartec69_at_[hidden])
Date: 2019-11-25 19:15:08
On Mon, Nov 25, 2019 at 3:43 PM Ville Voutilainen <
> 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.
The harm isn't to the implementations, it's to the users that want
portability and the already-shipped third-party code that uses the old name.
SG10 list run by firstname.lastname@example.org