On Thu, 14 Jun 2018 at 19:57, Richard Smith <rich...@metafoo.co.uk> 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@isocpp.open-std.org > http://www.open-std.org/mailman/listinfo/features >
_______________________________________________ Features mailing list Features@isocpp.open-std.org http://www.open-std.org/mailman/listinfo/features
