Here is what I have done to try to capture the changes to C++17 from Jacksonville.
The vast majority of the library proposals include a proposed name for the feature-test macro. (Yay!) They are all included in the table. But none of the language proposals did, and a few of the library proposals didn't say anything.
I have added some proposals of my own, marked with one question mark where I'm fairly confident my proposal is reasonable, and two question marks where I'm less confident. Note that for range-based for, I have proposed to bump an existing macro. (The target of the link from the new value is in SD-6; it dangles in this document.)
For the enum class value change, I haven't yet taken the time to try to decide whether a macro would be worthwhile. For unary folds and the "design mistake", I propose that no macro is needed, and include my rationale.
The fundamentals TS (and to a lesser degree the parallelism TS) make it not obvious what to do about keeping the table sorted by primary section number. Another question is, should every macro name added by such an omnibus document link to the same rationale section?
Most of the document links are broken now, but should start working when the post-meeting mailing is posted.
| Doc. No. | Title | Primary Section | Macro Name | Value | Header |
|---|---|---|---|---|---|
| P0245R1 | Hexadecimal floating literals for C++ | 2.13 | __cpp_hex_float ? |
201603 | predefined |
| P0018R3 | Lambda Capture of *this by Value as [=,*this] | 5.1 | __cpp_capture_this ??
__cpp_capture_this_object ?? |
201603 | predefined |
| P0170R1 | Wording for Constexpr Lambda | 5.1 | __cpp_constexpr_lambda ? |
201603 | predefined |
| P0184R0 | Generalizing the Range-Based For Loop | 6.5 | __cpp_range_based_for ? |
201603 | predefined |
| P0188R1 | Wording for [[fallthrough]] attribute | 7.6 | __has_cpp_attribute(fallthrough) |
201603 | predefined |
| P0189R1 | Wording for [[nodiscard]] attribute | 7.6 | __has_cpp_attribute(nodiscard) |
201603 | predefined |
| P0212R1 | Wording for [[maybe_unused]] attribute | 7.6 | __has_cpp_attribute(maybe_unused) |
201603 | predefined |
| P0017R1 | Extension to aggregate initialization | 8.5 | __cpp_aggregate_bases ?? |
201603 | predefined |
| P0138R2 | Construction Rules for enum class Values | 8.5 | ??? | 201603 | predefined |
| P0036R0 | Unary Folds and Empty Parameter Packs | 14.5 | none ? | ||
| P0154R1 | constexpr std::hardware_{constructive,destructive}_interference_size | 18.6 | __cpp_lib_thread_hardware_interference_size
__cpp_lib_hardware_interference_size ?
|
201603 | <new> |
| P0033R1 | Re-enabling shared_from_this | 20.8 | __cpp_lib_enable_shared_from_this
|
201603 | <memory> |
| P0005R4 | Adopt not_fn from Library Fundamentals 2 for C++17 | 20.9 | __cpp_lib_not_fn
|
201603 | <function> |
| P0253R1 | Fixing a design mistake in the searchers interface in Library Fundamentals | 20.9 | none ? | ||
| P0185R1 | Adding [nothrow-]swappable traits | 20.10 | __cpp_lib_is_swappable
|
201603 | <type_traits> |
| P0077R2 | is_callable, the missing INVOKE related trait | 20.10 | __cpp_lib_is_callable
|
201603 | <type_traits> |
| P0220R1 | Adopt Library Fundamentals V1 TS Components for C++17 | 20.4 | __cpp_lib_apply |
201603 | <tuple> |
| 20.8 | __cpp_lib_shared_ptr_arrays |
201603 | <memory> |
||
| 20.9 | __cpp_lib_boyer_moore_searching |
201603 | <functional> |
||
| 20 |
__has_include(<optional>)__has_include(<any>)__has_include(<string_view>)__has_include(<memory_resource>)
|
1 | predefined | ||
| 20 | __cpp_lib_optional |
201603 | <optional> |
||
| 20 | __cpp_lib_any |
201603 | <any> |
||
| 20 | __cpp_lib_string_view |
201603 | <string_view> |
||
| 20 | __cpp_lib_memory_resource |
201603 | <memory_resource> |
||
| P0272R1 | Give 'std::string' a non-const '.data()' member function | 21.4 | __cpp_lib_string_data ?
__cpp_lib_basic_string_data ?
|
201603 | <string> |
| P0031R0 | A Proposal to Add Constexpr Modifiers to reverse_iterator, move_iterator, array and Range Access | 24.3 | __cpp_lib_array_constexpr
|
201603 | <iterator> |
| P0025R0 | An algorithm to "clamp" a value between a pair of boundary values | 25.4 | __cpp_lib_clamp
|
201603 | <algorithm> |
| P0024R2 | The Parallelism TS Should be Standardized | 25, 26 | __cpp_lib_parallel_algorithm
|
201603 | <algorithm> <numeric> |
| 18 | __has_include(<exception_list>) |
1 | predefined | ||
__cpp_lib_exception_list ? |
201603 | <exception_list> |
|||
| 20 | __has_include(<execution_policy>) |
1 | predefined | ||
__cpp_lib_execution_policy ? |
201603 | <execution_policy> |
|||
| P0030R1 | Proposal to Introduce a 3-Argument Overload to std::hypot | 26.8 | __cpp_lib_hypot
|
201603 | <cmath> |
| P0226R1 | Mathematical Special Functions for C++17 | 26.8 | __cpp_lib_math_special_functions
|
201603 | <cmath> |
| P0218R1 | Adopt the File System TS for C++17 | 27.10 | __has_include(<filesystem>) |
1 | predefined |
__cpp_lib_filesystem
|
201603 | <filesystem> |
|||
| P0152R1 | constexpr atomic<T>::is_always_lock_free | 29.5 | __cpp_lib_atomic_is_always_lock_free |
201603 | <atomic> |
The fundamentals TS proposed a macro for each added component declared in a new header; the parallelism TS added new headers, but just proposed a single over-arching macro. Should every new header have its own macro when it's added?
This could be considered a bug fix, or it could be considered to remove an existing feature. Either way, it's not clear that a feature-test macro would be useful.
Many thanks to Daniel for sending me this example – unsolicited!
Example:
template<class T>
void my_swap(T& x, T& y)
#if __cpp_lib_is_swappable
noexcept(std::is_swappable_v<T>); // Covers all Lvalue Swappable cases
#else
noexcept(
std::is_nothrow_move_constructible_v<T> &&
std::is_nothrow_move_assignable_v<T>
);
#endif
This probably doesn't belong here long-term; it's just for short-term confirmation. Omitted:
This is a fix that is applied to the searchers interface at the same time that it is incorporated into the standard. The unfixed state exists only in the TS, which has its own macro name and value. The new macro for the searchers interface in the standard, with its new value, will be enough to indicate that this fix is applied.