<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 30 Aug 2019 at 02:18, Ben Craig &lt;<a href="mailto:ben.craig@ni.com">ben.craig@ni.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
<div dir="auto" style="direction:ltr;margin:0px;padding:0px;font-family:sans-serif;font-size:11pt;color:black">
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 &quot;wrong&quot; order.<br></div></div></blockquote><div><br></div><div>There&#39;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&#39;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&#39;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.</div><div><br></div><div>I think keeping the usage of these macros simpler is more important than making them as fine-grained as possible. That&#39;s also the direction that LWG have been taking with macros for &quot;constexpr all the things&quot;, 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&#39;m inconsistent ;-) But my rationale in both cases is simplifying the usage experience).</div><div><br></div><div><br></div><div><br></div></div></div>