| Doc. No.: | D3948 |
|---|---|
| Date: | 2014-02-20 |
| Reply to: | Clark Nelson |
| Title: | Feature-testing recommendations for C++ |
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.
| Date | Doc. No. | Title | New Header |
|---|---|---|---|
| 2013-04 | N3505 | Filesystem Library Proposal | <filesystem> |
| 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.
| Date | Doc. No. | Title |
|---|---|---|
| 2014-02 | N3929 | Technical Specification: Concepts |
| 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 |
| 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> |
| Date | Doc. No. | Title |
|---|---|---|
| 2014-02 | N3850 | Working Draft, Technical Specification for C++ Extensions for Parallelism |
| Date | Doc. No. | Title |
|---|---|---|
| 2014-02 | N3785 | Executors and schedulers |
| 2014-02 | N3857 | Improvements to std::future<T> and Related APIs |
| Date | Doc. No. | Title |
|---|---|---|
| 2014-02 | N3919 | Transactional Memory Support for C++ |