On Thu, 29 Aug 2019 at 04: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). > > 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) > - Familiar syntax for generic lambdas (P0428R2) > - make_shared for arrays (P0674R1) > > Albuquerque 2017 (201711) > - Range-for with initializer (P0614R1, bump __cpp_range_based_for?) > - ADL and function templates (P0846R0) > - Default constructible and assignable lambdas (P0624R2) > - Lambdas in unevaluated contexts (P0315R4) > - remove_cvref (P0550R2) > In theory remove_cvref_t<T> *could* be slightly more efficient (fewer template instantiations) than remove_cv_t<remove_reference_t<T>> but I'm not sure it's worth adding a macro for. > - 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) > - Symmetry for <=> (P0905R1, should bump __cpp_impl_three_way_comparison?) > - Comparing unordered containers (P0809R0) > - <chrono> for calendars and timezones (P0355R7) > I was going to suggest bumping __cpp_lib_chrono, but that's had other updates, and calendars probably deserve their own macro. > - Manipulators for synchronized buffered ostream (P0753R2, should bump > whatever syncbuf adds) > - span (P0122R7) > > Rapperswil 2018 (201806) > - Virtual calls in constexpr (P1064R0) > - contains (P0458R2) > Does this need a macro? If it's not supported the fallback is to use c.find(key) != c.end(), so if you have to write that anyway, you might as well not bother using contains. > - constexpr array comparison? (P1023R0) > I think there's an LWG issue (in Tentatively Ready state) about this. > - 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) > - immediate functions (P1073R3) > - optional/variant propogate triviality (P0602R4) > I'm undecided whether this needs to be exposed via feature test macros. > - visit<R> (P0655R1) > - constexpr pointer_traits (P1006R1, possibly with __cpp_lib_constexpr) > - unwrap_ref_decay / unwrap_reference (P0318R1) > - sane variant converting ctor (P0608R3) > This is a breaking change, but I'm not sure whether there's anything you can do differently if the feature is implemented or not, so no need for a macro? - assume_aligned (P1007R3) > - smart pointer with default init (P1020R1) > - should span be regular (P1085R2, just bump from the other span paper) > I agree with a value bump not a new macro. > > Kona 2019 (201902) > - extending structured bindings (P1091R3, P1381R1) > - <=> != == (should bump both the class nttp macro, and the 3-way > comparison macro) > - polymorphic_allocator (P0339R6) > - std:ssize (P1227R2) > - more span things (P1024R3) > Bump __cpp_lib_span again. > > 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) >
_______________________________________________ Features mailing list Features@isocpp.open-std.org http://www.open-std.org/mailman/listinfo/features
