<div dir="ltr"><div dir="ltr">On Fri, Oct 4, 2019 at 6:56 AM David Vandevoorde via Lib &lt;<a href="mailto:lib@lists.isocpp.org">lib@lists.isocpp.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 style="overflow-wrap: break-word;">Thanks for that work, Barry!</div></blockquote><div><br></div><div>+1, this is great.<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 style="overflow-wrap: break-word;"><div>I don’t disagree with any of your recommendations, and wholeheartedly agree with your constexpr changes.</div><div><br></div><div>While going through it I found myself really not liking the name “__cpp_familiar_template_lambda”: I find it quite opaque.  Is there is an opportunity to rename it to “__cpp_expl_lambda_template_parameters” or something like that?</div></div></blockquote><div><br></div><div>I&#39;d prefer that we just bump the value of __cpp_generic_lambdas for this rather than adding a new macro.</div><div><br></div><div>__cpp_impl_constexpr_members_defined : not a huge fan of the name, but if it&#39;s likely only going to be used in the stdlib implementation, maybe that&#39;s fine.</div><div><br></div><div>__cpp_lib_remove_cvref : does this need a macro? It seems like code wishing to support old compilers could define it themselves or unconditionally use remove_reference + remove_cv (I think this fails the &quot;you lose nothing by always behaving like the feature is not present&quot; test, unless I&#39;ve overlooked a use case). I&#39;m wondering the same thing for __cpp_lib_starts_ends_with. I&#39;d imagine a typical usage of that macro would be something like this (possibly factored out into a helper function):</div><div><br></div><div>#if __cpp_lib_starts_ends_with</div><div>  if (s.starts_with(&quot;foo&quot;))</div><div>#else</div><div>  if (s.size() &gt;= 3 &amp;&amp; s.compare(0, 3, &quot;foo&quot;))</div><div>#endif</div><div><br></div><div>I don&#39;t think that&#39;s worthwhile when you could instead write:</div><div><br></div><div>  // TODO(c++20): replace with s.starts_with(&quot;foo&quot;)</div><div><div>  if (s.size() &gt;= 3 &amp;&amp; s.compare(0, 3, &quot;foo&quot;))</div></div><div><br></div><div>Same thought for: __cpp_lib_type_identity, __cpp_lib_unwrap_ref (small convenience functionality that you can write yourself with no loss of functionality if you need it and can&#39;t depend on it being in the library).</div><div><br></div><div>__cpp_lib_constexpr_complex, __cpp_lib_constexpr_array_comparisons, __cpp_lib_constexpr_pointer_traits : I seem to recall a discussion in L(E?)WG about moving away from fine-grained constexpr feature test macros for the stdlib towards periodically bumping __cpp_lib_constexpr. How do these fit into that?<br></div><div><br></div><div>Regarding the new set of constexpr macros (__cpp_constexpr_virtual, try_catch, ...): do those benefit any implementation? (Clang at least has already released some of these features without the additional macros, so they&#39;re no help there for the previous release, and now implements the full set of these, so the fine-grained macros are no help for the next release either.) I think we need to be careful about adding too many macros -- each feature test macro we add introduces a small amount of overhead to every compilation, and that adds up. (Incidentally this is why the original proposal was for a single __has_feature(x) mechanism: that avoids the need to pre-populate all the feature test macros in the macro table. But that ship has sailed.) I think it&#39;s preferable for users to just have a value that means &quot;you get to use the C++20 constexpr rules&quot; if no-one is going to ship a compiler that has only part of the rules (apart from dynamic allocation, which has its own macro).</div><div><br></div><div>For __cpp_nodiscard_reason: I&#39;m opposed to adding this macro in isolation. Either we need to accept that version numbers for feature test macros don&#39;t work (the magic numbers are too magical) and completely rethink our approach, or we do not have adequate rationale for this.</div><div><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 style="overflow-wrap: break-word;"><div><span style="white-space:pre-wrap">        </span>Daveed<br><div><br><blockquote type="cite"><div>On Oct 3, 2019, at 11:56 PM, Barry Revzin via Core &lt;<a href="mailto:core@lists.isocpp.org" target="_blank">core@lists.isocpp.org</a>&gt; wrote:</div><br><div><div dir="ltr"><div>Hey SG10, CWG, and LWG,</div><div><br></div><div>I went through the past few years of straw polls and put together a suggestion of what feature-test macros are missing: I&#39;m proposing that about two dozen need to be added. The draft can be found here: <a href="https://brevzin.github.io/sd6/papers/d1902r0.html" target="_blank">https://brevzin.github.io/sd6/papers/d1902r0.html</a>. <br></div><div><br></div><div>I included every paper on the straw polls pages, so if anybody has motivation for a macro for one of the papers I listed as &quot;no macro necessary,&quot; please let me know. Also, if you disagree with any of my recommendations, also let me know. I already pruned an earlier list with some help, and I&#39;d like to get this right.</div><div><br></div><div>I wanted to get this out earlier than the weekend before the deadline, but... that didn&#39;t happen.<br></div><div><br></div><div>Barry<br></div></div>
_______________________________________________<br>Core mailing list<br><a href="mailto:Core@lists.isocpp.org" target="_blank">Core@lists.isocpp.org</a><br>Subscription: <a href="https://lists.isocpp.org/mailman/listinfo.cgi/core" target="_blank">https://lists.isocpp.org/mailman/listinfo.cgi/core</a><br>Link to this post: <a href="http://lists.isocpp.org/core/2019/10/7332.php" target="_blank">http://lists.isocpp.org/core/2019/10/7332.php</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>
Lib mailing list<br>
<a href="mailto:Lib@lists.isocpp.org" target="_blank">Lib@lists.isocpp.org</a><br>
Subscription: <a href="https://lists.isocpp.org/mailman/listinfo.cgi/lib" rel="noreferrer" target="_blank">https://lists.isocpp.org/mailman/listinfo.cgi/lib</a><br>
Link to this post: <a href="http://lists.isocpp.org/lib/2019/10/13732.php" rel="noreferrer" target="_blank">http://lists.isocpp.org/lib/2019/10/13732.php</a><br>
</blockquote></div></div>