C++ Logo

sg10

Advanced search

Re: [SG10] Missing feature-test macros since 2017

From: Barry Revzin <barry.revzin_at_[hidden]>
Date: Mon, 9 Sep 2019 21:17:46 -0500
On Sun, Sep 8, 2019 at 8:04 PM Richard Smith <richard_at_[hidden]> wrote:

> On Wed, 28 Aug 2019 at 20:05, Barry Revzin <barry.revzin_at_[hidden]> 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

Received on 2019-09-10 04:17:56