This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

3418. Deprecated free functions in <atomic>

Section: 32.5.9 [atomics.nonmembers] Status: New Submitter: Alisdair Meredith Opened: 2020-03-19 Last modified: 2020-09-06

Priority: 3

View all issues with New status.

Discussion:

Paper P1831R1 deprecated the volatile-qualified member functions of std::atomic unless is_always_lock_free is true. 32.5.9 [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-03-29; Daniel provides wording]

The suggested wording changes for 32.5.9 [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 16.3.2.4 [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.

[2020-03-30; Tim improves wording]

[2020-04-25 Issue Prioritization]

Priority to 3 after reflector discussion.

Proposed resolution:

This wording is relative to N4861.

1. Modify 32.5.9 [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.

2. Modify D.23.2 [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;