brevzin / sd6 Goto Github PK

• November 2020
• February 2021
• June 2021
• October 2021

(Concerning p1902r1)

Since unwrap_reference and unwrap_ref_decay are defined in <functional> ([functional.syn]), their feature test macro should also be defined there.

(unwrap_reference and unwrap_ref_decay depend on reference_wrapper, so it makes sense for them to live in <functional>.)

The 2020-2-27 revision of the official doc adds both __cpp_coroutines and __cpp_impl_coroutine as Language Feature-Test Macros, referencing (mostly) the same proposal and having the same values. If my reading of the new Policies is correct, __cpp_coroutines should have been deprecated on arrival, and __cpp_impl_coroutine should prevail.

We should state a policy of: feature test macros testing for the presence of a single type trait FOO should be name __cpp_lib_FOO. We already do this for is_aggregate, is_final, is_invocable, is_layout_compatbile, is_null_pointer, is_pointer_interconvertible, is_swappable, and has_unique_object_representations.

__cpp_lib_enable_shared_from_this currently references P0074R0, but should be P0033R1.

P1902R1 mentions:

[P0415R1] (Constexpr for std::complex): this paper proposes to introduce the macro __cpp_lib_constexpr_complex. That is, introducing a new macro for this header.

But __cpp_lib_constexpr_complex isn't listed in the 'Wording' section, and thus is not added to the draft standard when applying P1902R1.

Go through Straw Polls page and add/update macros as appropriate.

P1902 involves making many updates.

P0433R2 has a __cpp_lib_deduction_guides but that apparently never got propagated anywhere.

SD-FeatureTest currently says "OOPS FORGOT" for the "Header(s)" of __cpp_lib_deduction_guides and __cpp_lib_modules. I see that this is being emitted by central machinery:

because these macros don't have recorded header_lists:

Unlike most macros:

For __cpp_lib_deduction_guides, it appears that LWG-3635 wants to add it, and it does specify a list of headers:

#define __cpp_lib_deduction_guides   201703L
  // also in <array>, <deque>, <forward_list>, <functional>, <list>, <map>,
  // <memory>, <optional>, <queue>, <regex>, <scoped_allocator>, <set>, <stack>,
  // <string>, <tuple>, <unordered_map>, <unordered_set>, <utility>, <valarray>,
  // <vector>

For __cpp_lib_modules, this absence is intentional; as P2465R3 explained:

Unlike all of the other library feature-test macros, this should not have a comment "// also in <HEADER>".

While the language-level support for C++ coroutines has an assigned macro (__cpp_coroutines), there is no corresponding macro for library-level support. Other features split between language and library features do have both sets of macros (cf. <concepts>). Note that simply testing __has_include (<coroutine>) is not in keeping with the idea of versioning feature support.

The obvious fix is to create a new macro, __cpp_lib_coroutines, and assign it a value of 201902L, in keeping with the language macro.

Says "Improving the Return Value of Erase-Like Algorithms II: Free erase/erase if" but should be erase_if (with underscore).

Shows up as "Add shift to" instead of "Add shift to <algorithm>"

.

SD-6 should document all of our policies for when to use feature test macros. It doesn't yet.