[expr.const.core] Blocking the thread of execution should not be a core constant expression

[eisenwave]

Full name of submitter (unless configured in github; will be published with the issue):

Reference (section label): [expr.const.core]

Prior discussion: cplusplus/draft#9298

Issue description

[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.

Suggested resolution

Add a bullet to [expr.const.core] paragraph 2:

 An expression E is a core constant expression unless the evaluation of E,
 following the rules of the abstract machine ([intro.execution]),
 would evaluate one of the following:
   - ...
   - an invocation of the va_arg macro ([cstdarg.syn]);
+  - an operation that blocks the thread of execution ([defns.block]);
   - a non-constant library call ([defns.nonconst.libcall]); or
   - ...

[safocl]

doesn't the text "- a non-constant library call ([defns.nonconst.libcall]);" already mean what is proposed (you just need to remove the corresponding one from the library calls)?

[eisenwave]

Just pointing to "non-constant library call" doesn't provide any answers as to whether wait is a constant expression. Non-constant library calls are by definition not core constant expressions and even listing them in [expr.const.core] is redundant.

Similarly, if you were to explain why std::swap between two dead objects is not a constant expression, you would point toward the lvalue-to-rvalue conversion inside swap being disallowed (https://eel.is/c++draft/expr.const.core#2.10.2). Saying it's not a constant expression because it's a non-constant library call would be circular and offer no explanation.

One could also say somewhere in library wording that blocking threads makes library calls non-constant, but we have traditionally legislated this in [expr.const.core], like listing restrictions on allocator<T>::[de]allocate there, or on std::current_exception().

[jensmaurer]

"non-constant library call" is used exactly once, in [library.c] p3:

A call to a C standard library function is a non-constant library call (3.35) if ...

I think the right way forward is to add text to the library wording to say that something that blocks is a non-constant library call, and then rely on the core hook for that.