C++ Logo


Advanced search

Re: [SG10] Missing feature-test macros since 2017

From: Jonathan Wakely <cxx_at_[hidden]>
Date: Thu, 5 Sep 2019 13:40:49 +0100
On Fri, 30 Aug 2019 at 02:18, Ben Craig <ben.craig_at_[hidden]> wrote:

> Is there consensus that bumping the value is the right design for feature
> additions? I see value bumping as valuable when a design changes (e.g. the
> many iterations of move semantics, the changing rules around spaceship),
> but when there is a feature addition, then there is the potential for
> implementors to do things in the "wrong" order.

There's a point where different macros for every feature becomes too
difficult for users. To understand what it means if __cpp_lib_feature_A and
__cpp_lib_feature_C are defined, but not __cpp_lib_feature_B, they can't
just consult the current working draft. They have to look at the actual
changes introduced by specific proposals, and reconstruct the supported API
themselves. A single macro with a bumped value is easier for them: it says
the feature is up to date with the working draft from that date, and they
can just look at the spec in that draft. If an implementation does feature
A and feature C, but not B, then they should only set the macro to the
value for A. Yes, that means the macro doesn't tell users that C is
available, but hopefully it will only be a short-term problem while the
implementation catches up with feature B.

I think keeping the usage of these macros simpler is more important than
making them as fine-grained as possible. That's also the direction that LWG
have been taking with macros for "constexpr all the things", and the
direction that Core took for [[nodiscard]] changes (although I happened to
think separate macros actually *does* help users in the nodiscard case,
because I'm inconsistent ;-) But my rationale in both cases is simplifying
the usage experience).

Received on 2019-09-05 14:41:01