Date: Thu, 14 Jun 2018 11:56:31 -0700
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
* P0542R5 contracts: [[expect]], [[ensures]], [[assert]]:
__has_cpp_attribute == 201806?
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
* P0542R5 contracts: [[expect]], [[ensures]], [[assert]]:
__has_cpp_attribute == 201806?
Received on 2018-06-14 20:56:57