C++ Logo

sg10

Advanced search

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

From: Richard Smith <richard_at_[hidden]>
Date: Sun, 8 Sep 2019 18:04:09 -0700
On Wed, 28 Aug 2019 at 20:05, Barry Revzin <barry.revzin_at_[hidden]> 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_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features
>

Received on 2019-09-09 03:36:15