<div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon, 9 Sep 2019, 19:17 Barry Revzin, &lt;<a href="mailto:barry.revzin@gmail.com">barry.revzin@gmail.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 Sun, Sep 8, 2019 at 8:04 PM Richard Smith &lt;<a href="mailto:richard@metafoo.co.uk" target="_blank" rel="noreferrer">richard@metafoo.co.uk</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 class="gmail_quote">On Wed, 28 Aug 2019 at 20:05, Barry Revzin &lt;<a href="mailto:barry.revzin@gmail.com" target="_blank" rel="noreferrer">barry.revzin@gmail.com</a>&gt; wrote:<br><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>Albuquerque 2017 (201711)<br>- Range-for with initializer (P0614R1, bump __cpp_range_based_for?)<br></div></div></blockquote><div><br></div><div>Not worthwhile. (Maybe, *maybe*, you&#39;re writing a statement-like macro and can give it a better expansion if this feature is available, but I think you can rewrite &#39;for (decl; range)&#39; as &#39;switch (decl; 0) case 0: for(range)&#39; in any such case.)</div></div></div></blockquote><div><br></div><div>I like that you go for switch (decl; 0) rather than if (decl; true) :-)</div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">That has dangling else problems :-)</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><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"><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"><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>Jacksonville 2018 (201803)<br>- Pack expansion in lambda init-capture (P0780R2)<br></div></div></blockquote><div><br></div><div>Leaning not worthwhile</div></div></div></blockquote><div><br></div><div>I think this one is worthwhile. It&#39;s the difference between a less and more expensive compile time solution (i.e. use a pack or use a tuple). And I had people ask me about this one specifically.</div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">OK, that&#39;s good enough for me.</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><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"><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"><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>- Symmetry for &lt;=&gt; (P0905R1, should bump __cpp_impl_three_way_comparison?)<br></div></div></blockquote><div><br></div><div>Yes, we should have a feature test macro for this. Bumping the macro version seems reasonable in isolation, but we should look at the papers affecting &lt;=&gt; more holistically. I doubt we need anything more than the old macro version and a version meaning &quot;what we have in the C++20 CD&quot; -- tracking the path by which we reached that point isn&#39;t interesting if no-one has implemented a mid-way point.</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>- Comparing unordered containers (P0809R0)<br>- &lt;chrono&gt; for calendars and timezones (P0355R7)<br>- Manipulators for synchronized buffered ostream (P0753R2, should bump<br>  whatever syncbuf adds)<br>- span (P0122R7)<br><br>Rapperswil 2018 (201806)<br>- Virtual calls in constexpr (P1064R0)<br></div></div></blockquote><div><br></div><div>Needs motivation</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>- contains (P0458R2)<br>- constexpr array comparison? (P1023R0)<br>- shift algorithms (P0769R2)<br>- identity (P0887R1)<br>- is_nothrow_convertible (P0758R1)<br>- integral power of 2 functions (P0556R3)<br><br>San Diego 2018 (201811)<br>
- things that bump constexpr (try/catch P1002R1, dynamic_cast, 
polymorphic typeid P1327R1, and change active member of union P1330R0)
</div></div></blockquote><div><br></div><div>Needs motivation</div></div></div></blockquote><div><br></div><div>Implementing constexpr operator= for sum types (optional/expected/variant... not the std ones but user-defined implementations) for the last one, at least. </div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">Good point. Determining whether you can mark functions as constexpr seems like a reasonable motivation for at least try/catch and changing the active union member. Probably also for virtual function calls. How many feature test macros do we want? (Clang already implemented all of these, so we&#39;ll start advertising them all in the same release and don&#39;t need separate macros; I don&#39;t know about other implementations.)</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><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"><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"><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>- immediate functions (P1073R3)<br></div></div></blockquote><div><br></div><div>Yes, I think we should have a macro for this. I think it&#39;s reasonable to write functions that are consteval in C++20 and constexpr in C++17 (things you really want to only evaluate at compile time, but for which you can&#39;t enforce that until C++20).</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 dir="ltr"><div>- optional/variant propogate triviality (P0602R4)<br>- visit&lt;R&gt; (P0655R1)<br>- constexpr pointer_traits (P1006R1, possibly with __cpp_lib_constexpr)<br>- unwrap_ref_decay / unwrap_reference (P0318R1)<br>- sane variant converting ctor (P0608R3)<br>- assume_aligned (P1007R3)<br>- smart pointer with default init (P1020R1)<br>- should span be regular (P1085R2, just bump from the other span paper)<br><br>Kona 2019 (201902)<br>- extending structured bindings (P1091R3, P1381R1)<br></div></div></blockquote><div><br></div><div>Needs motivation</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>- &lt;=&gt; != == (should bump both the class nttp macro, and the 3-way comparison macro)<br></div></div></blockquote><div><br></div><div>Yes, we should do something about this. Per the above I think we should take a holistic view for &lt;=&gt; feature macros. Bumping the class type NTTP macro makes sense to me. Does any vendor advertise the old value yet?</div></div></div></blockquote><div><br></div><div>I&#39;ll think about the &lt;=&gt; case some more specifically.</div><div><br></div><div>Barry<br></div></div></div>
</blockquote></div></div>