On Mon, 9 Sep 2019, 19:17 Barry Revzin, <barry.revzin@gmail.com> wrote:
On Sun, Sep 8, 2019 at 8:04 PM Richard Smith <richard@metafoo.co.uk> wrote:
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) :-)

That has dangling else problems :-)

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.

OK, that's good enough for me.

- 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. 

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.)

- 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