C++ Logo

sg10

Advanced search

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

From: Richard Smith <richard_at_[hidden]>
Date: Mon, 9 Sep 2019 19:36:57 -0700
On Mon, 9 Sep 2019, 19:17 Barry Revzin, <barry.revzin_at_[hidden]> wrote:

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

That has dangling else problems :-)

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

OK, that's good enough for me.

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

Good point. Determining whether you can mark functions as constexpr seems
like a reasonable motivation for at least try/catch and changing the active
union member. Probably also for virtual function calls. How many feature
test macros do we want? (Clang already implemented all of these, so we'll
start advertising them all in the same release and don't need separate
macros; I don't know about other implementations.)

- 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:37:21