US356 31.07.1 [atomics.ref.operations] p10 Make atomic_ref<T>::is_lock_free type-specific, not object-specifc LWG 3249

[wg21bot]

atomic_ref::is_lock_free should require that the result only depend on the type of the object, not the specific object. The current specification is inconsistent with atomic<T>. (See [atomics.lockfree] 31.5p3.) This test is primarily useful to determine whether a particular algorithm can or should be used. If the result can vary based on object identity, that is not possible. There is no way to ask whether the property holds for all relevant objects until all of the objects are actually available for testing. Note that is_always_lock_free does not fully serve this purpose, since is_lock_free() may vary at run time depending on hardware characteristics, while still being consistent per type. This was the subject of recent reflector discussion.

Proposed change: Apply the PR for LWG3249, and replicate the equivalent wording here. Possibly consider making the is_lock_free member function static. That appears to make the member function behavior less surprising, at the cost of an inconsistency with the C-constrained free function.

[ogiroux]

Recommend removing the instance-dependence of atomic_ref::is_lock_free(), in response to US 356: SF F N A SA 3 3 5 1 0 Consensus for change.

Recommend adding an instance-dependent atomic_ref::is_instance_lock_free(), in response to US 356: SF F N A SA 2 5 3 1 2 Not consensus for change in an NB ballot process SA: would like to see an implementation that would use that freedom SA: we can add this later and I don't yet know what it's for - to know 1 instance is lock-free, but another isn't

Recommend making atomic_ref::is_lock_free() static, in response to US 356: SF F N A SA 3 5 3 1 2 Not consensus for change in an NB ballot process SA: it doesn't match atomic_ref SA: we often write type that is generic over the atomic type

[tituswinters]

LEWG in Belfast: Approve LWG 3249, forward to LWG.

[jensmaurer]

Accepted.