On Wed, 28 Aug 2019 at 20:05, Barry Revzin <barry.rev...@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 >
_______________________________________________ Features mailing list Features@isocpp.open-std.org http://www.open-std.org/mailman/listinfo/features
