C++ Logo


Advanced search

Re: [SG10] [isocpp-lib] [EXTERNAL] __cpp_lib_constexpr_algorithm*s*

From: Casey Carter <cartec69_at_[hidden]>
Date: Mon, 25 Nov 2019 17:15:08 -0800
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.

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.

Received on 2019-11-25 19:17:43