Created on 2020-03-19.00:00:00 last changed 1 month ago
This wording is relative to N4861.
Modify [atomics.nonmembers] as indicated:
-1- A non-member function template whose name matches the pattern atomic_f or the pattern atomic_f_explicit invokes the member function f, with the value of the first parameter as the object expression and the values of the remaining parameters (if any) as the arguments of the member function call, in order. An argument for a parameter of type atomic<T>::value_type* is dereferenced when passed to the member function call. If no such member function exists, the program is ill-formed.
Modify [depr.atomics.volatile], annex D, as indicated:
If an atomic specialization has one of the following overloads, then that overload participates in overload resolution even if atomic<T>::is_always_lock_free is false:void store(T desired, memory_order order = memory_order::seq_cst) volatile noexcept; […] T* fetch_key(ptrdiff_t operand, memory_order order = memory_order::seq_cst) volatile noexcept;
[ 2020-04-25 Issue Prioritization ]
Priority to 3 after reflector discussion.
[ 2020-03-30; Tim improves wording ]
[ 2020-03-29; Daniel provides wording ]
The suggested wording changes for [atomics.nonmembers] attempts to make clear that any of the specification elements of the member function (including but not restricted to Constraints: elements) are also imposed on the corresponding non-member function template. According to [structure.specifications], the wording "the semantics of the code sequence are determined by the Constraints,[…], and Error conditions specified for the function invocations contained in the code sequence." should realize the wanted effect. The advantage of this more general wording form is that we don't need to to worry in case that in the future Constraints: elements of the member functions are modified.
Paper P1831R1 deprecated the volatile-qualified member functions of std::atomic unless is_always_lock_free is true. [atomics.nonmembers] maps free functions calls, declared in the <atomic> header, to those member functions, but does not deprecate them under the same circumstances.I have confirmed with the paper author that the intended design was to deprecate these too, but currently we have no wording.
|2020-04-25 11:17:12||admin||set||messages: + msg11231|
|2020-03-30 15:29:10||admin||set||messages: + msg11180|
|2020-03-29 13:50:27||admin||set||messages: + msg11175|
|2020-03-29 13:50:27||admin||set||messages: + msg11174|