On Thu, 14 Jun 2018 at 19:57, Richard Smith <richard_at_[hidden]> wrote:

> Hi,
>
> It looks like some papers that deserve feature-test macros have slipped
> through the cracks. I've looked through the core language papers only
> (someone would need to do a similar exercise for the library papers); the
> following C++20 features seem to have a clear case for having feature test
> macros, but lack them:
>
> * P0409R2 allow lambda-capture [=, this]: a [=] capture that captures
> this is deprecated in C++20, so detecting that the replacement is available
> seems useful. Maybe __cpp_capture_equals_this == 201707?
> * P0734R0 concepts: it is reasonable to use concepts where available and
> fall back to other techniques otherwise, since concepts can provide a
> better experience for library users. __cpp_concepts == 201707 (but see
> below, I don't expect anyone to use this value)
> * P0859R0 when are constexpr member functions defined? This is a DR, but
> there are cases where a library would wish to declare a function as
> constexpr only for implementations implementing this paper. I would suggest
> bumping __cpp_constexpr to 201711 for this.
> * P0515R3 consistent comparison: particularly with non-type template
> parameters of class type, libraries may want to default operator<=> when
> possible and define traditional comparison operators otherwise. This needs
> both a language macro and a library macro.
> * P0857R0 functionality gaps in constraints. __cpp_concepts == 201711
> * P0905R1 symmetry for spaceship. Bump the feature test macro added for
> P0515R3?
> * P0722R3 destroying operator delete (being discussed in another thread)
>
> For these ones, I'm not sure whether there'd be a use case that we want to
> support (under the "if you want to be portable, don't use the feature"
> argument):
>
> * P0683R1 default member initializers for bit-fields
> * P0306R4 __VA_OPT__
> * P0329R4 designated initialization
> * P0428R2 template syntax for generic lambdas
> * P0614R1 range-based for with initializer
> * P0846R0 ADL and non-visible function templates
> * P0692R1 access checking on specialization
> * P0624R2 default constructible and assignable stateless lambdas
> * P0315R4 lambdas in unevaluated contexts
> * P0962R1 relaxing range-based for customization point rules
> * P0969R0 structured bindings for accessible but non-public members
> * P0962R1 relaxing structured binding customization point rules
> * P0634R4 down with typename
> * P0780R2 pack expansion in lambda init-capture
> * P1064R0 virtual function calls in constant expressions
> * P1008R1 prohibit aggregates with user-declared constructors
> * P1120R0 consistency improvements for <=> and other operators
>
> These papers got feature-test macros added when we merged SD-6 into the
> working paper and we will need updates in P0096 to match:
>
> * P0840R2 [[no_unique_address]] attribute (__has_cpp_attribute == 201803)
> * P0479R5 [[likely]] and [[unlikely]] attributes (__has_cpp_attribute ==
> 201803)
>
> These papers propose or imply the addition of feature test macros and
> we'll presumably need to update P0096 to match:
>
> * P0732R0 __cpp_nontype_template_parameter_class == 201806
> * P0892R2 __cpp_explicit_bool == 201806
>

It's been suggested that __cpp_conditionally_explicit is a better name,
because "explicit bool" could mean something other than "explicit(bool)"
i.e. the parentheses are necessary to describe the feature.




> * P0542R5 contracts: [[expect]], [[ensures]], [[assert]]:
> __has_cpp_attribute == 201806?
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features
>