<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"><<a href="mailto:clark.nelson@intel.com" target="_blank">clark.nelson@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> The row for __cpp_lib_not_fn says the header is <function> which<br>
> should be <functional><br>
<br>
</span>Thanks.<br>
<span class=""><br>
> The row for __cpp_lib_lock_guard_variadic says the header is<br>
> <thread> but lock_guard is defined in <mutex><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'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'm just going through them all now and writing some tests for them.</div><div><br></div><div>I'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 <memory> (specifically, the shared_ptr helper type owner_less), and all the original transparent operator changes only affect <functional>, so we might want to say that it's defined by <memory> as well. I'm ambivalent about that though. It's probably OK to leave it as only <functional>.</div><div><br></div><div><br></div><div> </div></div><br></div></div>