On Wed, 28 Aug 2019 at 20:05, Barry Revzin <barry.revzin@gmail.com> wrote:
Hey all,

I updated the SD-6 document on isocpp.org: https://wg21.link/sd6. I'm still having some CSS woes, but otherwise I updated the original document with the feature-test macros that have been adopted since it was first written, and organized the table by macro so that it's easy to see the history of values (e.g. for CTAD: https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#__cpp_deduction_guides). Please let me know if anything is wrong there, or missing, or generally could be improved.

Also, I went through the Straw Polls pages to see if we missed any macros and made the following list. I tried to be as liberal as possible in determining whether people would attempt to write code in both the old and new way, so as to prefer to produce a list with some things we could reject rather than miss more things... so I expect several of these may not actually need a macro. Several of them didn't (like "down with typename" - presumably you would just... write typename).

In the below, interpret "Needs motivation" as "I can't off-hand think of a case where the conditionally using this feature would be beneficial, but maybe I'm not being imaginative enough." For those, I'd lean towards not adding a macro until / unless we have a concrete case that would benefit from them.

Similarly, interpret "Not worthwhile" as "I do not think we should provide a macro for this because the incremental benefit of using this feature compared to using a workaround is too small."

I'm considering only the core language changes for now.

Let me know what you think. What belongs, what doesn't belong, any opinions would be very helpful. I'm intending to write a paper for Belfast with whatever we all decide is actually missing:

Toronto 2017 (201707)
- Designated Initializers (P0329R4)

Needs motivation
 
- Familiar syntax for generic lambdas (P0428R2)

Needs motivation
 
- make_shared for arrays (P0674R1)

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

- ADL and function templates (P0846R0)

Not worthwhile
 
- Default constructible and assignable lambdas (P0624R2)

Needs motivation
 
- Lambdas in unevaluated contexts (P0315R4)

Not worthwhile -- there is a fairly lightweight syntactic workaround for the absence of this feature
 
- remove_cvref (P0550R2)
- syncbuf (P0053R7)
- to_address (P0653R2)
- constexpr for complex (P0415R1)
- atomic shared_ptr (P0718R2)
- floating point atomic (P0020R6)
- starts_with/ends_with (P0457R2)

Jacksonville 2018 (201803)
- Pack expansion in lambda init-capture (P0780R2)

Leaning not worthwhile
 
- 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

- 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?
 
- polymorphic_allocator (P0339R6)
- std:ssize (P1227R2)
- more span things (P1024R3)
to me. 
Cologne 2019 (201907
- mothership library paper introduces a new macro for no reason (P1614R2), should have just bumped __cpp_lib_three_way_comparison
- efficient stringbuf (P0408R7)

Barry
_______________________________________________
Features mailing list
Features@isocpp.open-std.org
http://www.open-std.org/mailman/listinfo/features