<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 3 August 2016 at 18:17, Nelson, Clark <span dir="ltr">&lt;<a href="mailto:clark.nelson@intel.com" target="_blank">clark.nelson@intel.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; The row for __cpp_lib_not_fn says the header is &lt;function&gt; which<br>
&gt; should be &lt;functional&gt;<br>
<br>
</span>Thanks.<br>
<span class=""><br>
&gt; The row for __cpp_lib_lock_guard_variadic says the header is<br>
&gt; &lt;thread&gt; but lock_guard is defined in &lt;mutex&gt;<br>
<br>
</span>OK, thanks again. As it turns out, it was published that way on <a href="http://isocpp.org" rel="noreferrer" target="_blank">isocpp.org</a>,<br>
so that&#39;s an even more substantive correction, about which we may want to<br>
say something in the rationale.<br><span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Sorry for not spotting that one sooner, I&#39;m just going through them all now and writing some tests for them.</div><div><br></div><div>I&#39;ve also noticed that for my paper P0074R0, the existing macro __cpp_lib_transparent_operators was changed, rather than adding a new one.The P0074R0 changes only affect &lt;memory&gt; (specifically, the shared_ptr helper type owner_less), and all the original transparent operator changes only affect &lt;functional&gt;, so we might want to say that it&#39;s defined by &lt;memory&gt; as well. I&#39;m ambivalent about that though. It&#39;s probably OK to leave it as only &lt;functional&gt;.</div><div><br></div><div><br></div><div> </div></div><br></div></div>