[SG10] Jacksonville additions

[Nelson, Clark]

I have made a start at the additions we will need to make to SD-6 to reflect
the JAX meeting; the result is attached.

I am specifically soliciting comments on everything in the document that
involves a question mark.

--
Clark Nelson            Chair, PL22.16 (ANSI C++ standard committee)
Intel Corporation       Chair, SG10 (C++ SG for feature-testing)
clark.nel...@intel.com  Chair, CPLEX (C SG for parallel language extensions)

Title: SD-6 additions from Jacksonville meeting



SD-6 additions from Jacksonville meeting

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.

Significant changes to C++17

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>

P0005R4: Adopt not_fn from Library Fundamentals 2 for C++17

P0017R1: Extension to aggregate initialization

P0018R3: Lambda Capture of *this by Value as [=,*this]

P0024R2: The Parallelism TS Should be Standardized

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?

P0025R0: An algorithm to "clamp" a value between a pair of boundary values

P0030R1: Proposal to Introduce a 3-Argument Overload to std::hypot

P0031R0: A Proposal to Add Constexpr Modifiers to reverse_iterator, move_iterator, array and Range Access

P0033R1: Re-enabling shared_from_this

P0036R0: Unary Folds and Empty Parameter Packs

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.

P0077R2: is_callable, the missing INVOKE related trait

P0138R2: Construction Rules for enum class Values

P0152R1: constexpr atomic<T>::is_always_lock_free

P0154R1: constexpr std::hardware_{constructive,destructive}_interference_size

P0170R1: Wording for Constexpr Lambda

P0184R0: Generalizing the Range-Based For Loop

P0185R0: Adding [nothrow-]swappable traits

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

P0188R1: Wording for [[fallthrough]] attribute

P0189R1: Wording for [[nodiscard]] attribute

P0212R1: Wording for [[maybe_unused]] attribute

P0218R1: Adopt the File System TS for C++17

P0220R1: Adopt Library Fundamentals V1 TS Components for C++17

This probably doesn't belong here long-term; it's just for short-term confirmation. Omitted:

• type_trait_variable_templates
• invocation_type
• function_erased_allocator
• promise_erased_allocator
• packaged_task_erased_allocator
• sample

P0226R1: Mathematical Special Functions for C++17

P0235R1: Fixing a design mistake in the searchers interface in Library Fundamentals

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.

P0245R1: Hexadecimal floating literals for C++

P0272R1: Give 'std::string' a non-const '.data()' member function

_______________________________________________
Features mailing list
Features@isocpp.open-std.org
http://www.open-std.org/mailman/listinfo/features