Feature-testing for C++ Technical Specifications
Doc. No.: N3948
Date: 2014-02-20
Reply to: Clark Nelson
Title: Feature-testing recommendations for C++

Feature-testing for C++ Technical Specifications

Introduction

One of the primary reasons for defining the feature-test macros for C++14 in a document separate from the standard was to avoid even the impression that standard features are optional. Because features described in a Technical Specification are by definition optional, it is not clear that there is good justification for putting feature-testing facilities for a TS in a different document.

It was important for someone to “back-fill” feature-testing facilities for the new features of C++14, so SG10 undertook that task. But going forward, it would probably be better for feature-testing to be considered as part of the design of a new feature, and a descriptive and unique macro name selected, when necessary, by those who understand it best.

In addition, it is not clear that SG10 has yet adequately considered what to do about issues like ABI compatibility and versioning of interfaces for a library. It may well be that it would be more efficient for such discussions to happen in a library WG.

For all these reasons, it seems that discussion of feature-testing should not be happening exclusively within SG10.


The remainder of this document consists mainly of tables such as were used to drive discussions within SG10, to serve as starting points for discussions in other groups.

Each table row references some WG21 document that serves as the basis of (part of) a Technical Specification that is either currently in flight or taking off. The date of the WG21 vote referencing that document is also included: in SG10's approach, if a feature-test macro is needed, that date is used to determine what value the macro should take.

Some of these documents propose the addition of a new library header. This is called out, as the use of the header name with the __has_include feature can be used as a means of testing for a library feature. In addition, for some features, SG10 – or some especially diligent member thereof – has already proposed a macro name to be used to test for the presence of a new feature.

It should be understood that tracking features at the level of WG21 documents is just a guideline and handy initial default. In particular, not every proposal applied to a WD is considered a new feature (and therefore not all have an associated feature-test macro); for example, WG21 votes that refer to an issue-list document are not included below.

For each document, what should be done about feature-testing should be carefully considered. If a feature-test macro is not justified, rationale for the omission should be provided. It's also possible for a single document to describe what is actually more than one independent feature; if there are parts of a proposal that may be expected to be implemented separately, they should be considered to be separate features.

Some of the proposal documents referenced by a WG21 vote have been made moot by later events. For the sake of completeness, these are included below, but the text of the table row is struck out.

For summary and details of the work of SG10 so far, please see SD-6 at isocpp.org.

Project 18822: File System

Date Doc. No. Title New Header
2013-04 N3505 Filesystem Library Proposal <filesystem>

Project 19216: Networking

Date Doc. No. Title New Header
2013-09 N3783 Network Byte Order Conversion <net>

The above was mooted in 2014-02 (Issaquah), when N3783 was instead adopted into the Library Fundamentals TS. It is expected that in 2014-06 (Rapperswil), a revision of N3827 (Working Draft Technical Specification - URI) will be adopted as or into the WD for this project.

Project 19217: Concepts Lite

Date Doc. No. Title
2014-02 N3929 Technical Specification: Concepts

Project 19568: Library Fundamentals

Date Doc. No. Title New Header or Proposed Macro
2013-04 N3672 A proposal to add a utility class to represent optional objects <optional>
2014-02 N3783 Network Byte Order Conversion <net>
2014-02 N3793 A proposal to add a utility class to represent optional objects <experimental/optional>
2014-02 N3804 Any Library Proposal <experimental/any>
2014-02 N3843 A SFINAE-Friendly std::common_type __cpp_lib_common_type_sfinae
2014-02 N3866 Invocation type traits
2014-02 N3905 Extending std::search to use Additional Searching Algorithms
2014-02 N3915 apply() call a function with arguments from a tuple
2014-02 N3916 Polymorphic Memory Resources <experimental/memory_resource>
2014-02 N3920 Extending shared_ptr to Support Arrays
2014-02 N3921 string_view: a non-owning reference to a string <experimental/string_view>
2014-02 N3923 A SFINAE-Friendly std::iterator_traits __cpp_lib_iterator_traits_sfinae
2014-02 N3925 A sample Proposal __cpp_lib_sample
2014-02 N3932 Variable Templates For Type Traits

Project 19569: Arrays

Date Doc. No. Title New Header or Proposed Macro
2013-04 N3639 Runtime-sized arrays with automatic storage duration __cpp_runtime_arrays
2013-04 N3662 C++ Dynamic Arrays <dynarray>

Project 19570: Parallelism

Date Doc. No. Title
2014-02 N3850 Working Draft, Technical Specification for C++ Extensions for Parallelism

Project 19571: Concurrency

Date Doc. No. Title
2014-02 N3785 Executors and schedulers
2014-02 N3857 Improvements to std::future<T> and Related APIs

Project ?????: Transactional Memory

Date Doc. No. Title
2014-02 N3919 Transactional Memory Support for C++