On Wed, 28 Aug 2019 at 20:05, Barry Revzin <
barry.revzin@gmail.com> wrote:
Albuquerque 2017 (201711)
- Range-for with initializer (P0614R1, bump __cpp_range_based_for?)
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.)
I like that you go for switch (decl; 0) rather than if (decl; true) :-)
Jacksonville 2018 (201803)
- Pack expansion in lambda init-capture (P0780R2)
Leaning not worthwhile
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.
- Symmetry for <=> (P0905R1, should bump __cpp_impl_three_way_comparison?)
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.
- Comparing unordered containers (P0809R0)
- <chrono> for calendars and timezones (P0355R7)
- Manipulators for synchronized buffered ostream (P0753R2, should bump
whatever syncbuf adds)
- span (P0122R7)
Rapperswil 2018 (201806)
- Virtual calls in constexpr (P1064R0)
Needs motivation
- contains (P0458R2)
- constexpr array comparison? (P1023R0)
- shift algorithms (P0769R2)
- identity (P0887R1)
- is_nothrow_convertible (P0758R1)
- integral power of 2 functions (P0556R3)
San Diego 2018 (201811)
- things that bump constexpr (try/catch P1002R1, dynamic_cast,
polymorphic typeid P1327R1, and change active member of union P1330R0)
Needs motivation
Implementing constexpr operator= for sum types (optional/expected/variant... not the std ones but user-defined implementations) for the last one, at least.
- immediate functions (P1073R3)
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).
- optional/variant propogate triviality (P0602R4)
- visit<R> (P0655R1)
- constexpr pointer_traits (P1006R1, possibly with __cpp_lib_constexpr)
- unwrap_ref_decay / unwrap_reference (P0318R1)
- sane variant converting ctor (P0608R3)
- assume_aligned (P1007R3)
- smart pointer with default init (P1020R1)
- should span be regular (P1085R2, just bump from the other span paper)
Kona 2019 (201902)
- extending structured bindings (P1091R3, P1381R1)
Needs motivation
- <=> != == (should bump both the class nttp macro, and the 3-way comparison macro)
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?
I'll think about the <=> case some more specifically.
Barry