<div dir="ltr"><div dir="ltr">On Sun, Sep 8, 2019 at 8:04 PM Richard Smith <<a href="mailto:richard@metafoo.co.uk">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">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) :-)<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 dir="ltr"><div class="gmail_quote"><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>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.<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 dir="ltr"><div class="gmail_quote"><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>- 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. <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 dir="ltr"><div class="gmail_quote"><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>- 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>