Proposed resolution:

This wording is relative to N5054.

1. Modify [atomics.wait] as indicated:

   -1- Atomic waiting operations and atomic notifying operations provide a mechanism to wait for the value of an atomic object to change more efficiently than can be achieved with polling. An atomic waiting operation may block until it is unblocked by an atomic notifying operation, according to each function's effects. An atomic waiting operation that blocks is a non-constant library call ([defns.nonconst.libcall]).

   [Note 1: Programs are not guaranteed to observe transient atomic values, an issue known as the A-B-A problem, resulting in continued blocking if a condition is only temporarily met. — end note]

[atomics.types.operations] specifies that std::atomic<T>::wait is constexpr and that it blocks the thread if the given value is equal to the current value of the object. Other atomic waiting operations ([atomics.wait]) can also block, such as `std::atomic_flag::wait`.

P3309R3 argues that blocking the thread is not a constant expression because it exceeds implementation limits, but it is unclear which (if any) implementation limits are exceeded by blocking. One might also argue that blocking the thread violates the forward progress guarantee ([intro.progress]), which is undefined behavior and thus not a core constant expression, but this explanation is contrived.

See prior discussion at

• https://github.com/cplusplus/CWG/issues/1002

• https://github.com/cplusplus/draft/issues/9298

• https://stackoverflow.com/q/80000170/5740428