<div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon, 9 Sep 2019, 19:17 Barry Revzin, <<a href="mailto:barry.revzin@gmail.com">barry.revzin@gmail.com</a>> 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 <<a href="mailto:richard@metafoo.co.uk" target="_blank" rel="noreferrer">richard@metafoo.co.uk</a>> 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 <<a href="mailto:barry.revzin@gmail.com" target="_blank" rel="noreferrer">barry.revzin@gmail.com</a>> 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're writing a statement-like macro and can give it a better expansion if this feature is available, but I think you can rewrite 'for (decl; range)' as 'switch (decl; 0) case 0: for(range)' 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'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'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 <=> (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 <=> more holistically. I doubt we need anything more than the old macro version and a version meaning "what we have in the C++20 CD" -- tracking the path by which we reached that point isn'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>- <chrono> 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'll start advertising them all in the same release and don't need separate macros; I don'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'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'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<R> (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>- <=> != == (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 <=> 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'll think about the <=> case some more specifically.</div><div><br></div><div>Barry<br></div></div></div>
</blockquote></div></div>