<div dir="ltr"><div dir="ltr">On Fri, Aug 30, 2019 at 10:00 AM Jonathan Wakely &lt;<a href="mailto:cxx@kayari.org">cxx@kayari.org</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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 00:56, Aaron Ballman &lt;<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.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">On Thu, Aug 29, 2019 at 7:49 PM Barry Revzin &lt;<a href="mailto:barry.revzin@gmail.com" target="_blank">barry.revzin@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; We had two changes to [[nodiscard]] in Cologne:<br>
&gt;<br>
&gt; - P1301R4: [[nodiscard(&quot;should have a reason&quot;)]], for C++20<br>
&gt; - P1771R1: [[nodiscard]] for constructors, as a DR<br>
&gt;<br>
&gt; Currently, I put both under the 201907 block (<a href="https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#nodiscard" rel="noreferrer" target="_blank">https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#nodiscard</a>). But that means we have a [retroactive] C++17 feature whose macro has a value two years later. Is that fine? Alternatively, we could invent an earlier value for P1771R1 that&#39;s in the C++17 timeline.<br>
&gt;<br>
&gt; Thoughts?<br>
<br>
I raised this issue in Core and my understanding of the room was that<br>
this is not a serious problem for implementations. Implementations are<br>
expected to use the new value once they&#39;ve implemented both features.<br><br></blockquote><div><br></div><div>But what&#39;s the expected usage?</div><div><br></div><div>If I want to add a reason to my nodiscard attributes, I can do:</div><div><br></div><div>#if __cplusplus &gt; 201703L &amp;&amp; __has_cpp_attribute(nodiscard) &gt;= 201907</div><div># define NODISCARD(msg) [[nodiscard(#msg)]]</div><div>#elif __has_cpp_attribute(nodiscard)</div><div># define NODISCARD(msg) [[nodiscard]]</div><div>#else</div><div># define NODISCARD(msg)</div><div>#endif</div><div><br></div><div>This will not try to use a reason in C++17 code, even if the compiler supports doing so as an extension.</div></div></div></blockquote><div><br></div><div>Having to check both seems unfortunate.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>If we had a separate feature test macro for P1301R4 then I could just test for that, and be able to give a reason whenever the compiler supports it (even in C++11/14/17 code):</div><div><br></div><div>#if __cpp_nodiscard_reason &gt;= 201907<br></div><div><div># define NODISCARD(msg) [[nodiscard(#msg)]]</div><div>#elif __has_cpp_attribute(nodiscard)</div><div># define NODISCARD(msg) [[nodiscard]]</div><div>#else</div><div># define NODISCARD(msg)</div><div>#endif</div></div><div><br></div><div>So I think it&#39;s OK for the __has_cpp_attribute(nodiscard) value to mean that both new features are supported, but *also* adding a __cpp_nodiscard_reason macro might make things easier for users. This assumes that some implementations might choose to allow a nodiscard reason pre-C++20.</div></div></div></blockquote><div><br></div><div>For what it&#39;s worth, Jon Caves had said that he&#39;d received a user complaint about not having a specific macro for nodiscard w/reason and having to rely on the two different values instead. <br></div><div><br></div><div>Do we have any other examples in this vein?<br></div></div></div>