<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 4, 2019, 1:51 PM Richard Smith &lt;<a href="mailto:richardsmith@google.com">richardsmith@google.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank" rel="noreferrer">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>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><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></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I&#39;m okay with either of these.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><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).</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I wasn&#39;t sure about the traits. This one seems easily implantable (and the next two), so maybe not.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> 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></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">starts_with/ends_with seems similar to consistent erasure to me, which does have a macro. It&#39;s implementable but obnoxious.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><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></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Do you have a link? The only paper I currently have associated with __cpp_lib_constexpr on SD-6 is P1032R1.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></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></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Maybe we could just remove the restriction that constexpr functions have to be constant expressions for at least one set of arguments (otherwise ILNDR). That way, we could just mark things constexpr even if some compiler/library doesn&#39;t provide it yet?</div><div dir="auto"><br></div><div dir="auto">My motivation with these finer grained macros was to let you do conditional constexpr where possible. If implementations just batch these anyway, then maybe the fine grain wouldn&#39;t provide any value, and you just check for the one value you want?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><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></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Understood.</div><div dir="auto"><br></div><div dir="auto">Barry</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>