On Sun, Sep 8, 2019 at 8:04 PM Richard Smith <[email protected]> wrote:
> On Wed, 28 Aug 2019 at 20:05, Barry Revzin <[email protected]> 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
_______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
