On Fri, 30 Aug 2019 at 02:18, Ben Craig <[email protected]> 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).
_______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
