Proposed resolution (approved by CWG 2023-11-09):

Split into a separate paragraph and change 7.7 [expr.const] paragraph 5 as follows:

• ...
• an operation that would have undefined behavior as specified in Clause 4 [intro] through Clause 15 [cpp], excluding 9.12.3 [dcl.attr.assume] and 9.12.11 [dcl.attr.noreturn]; [ Footnote: ...]
• ...

It is unspecified whether E is a core constant expression if E satisfies the constraints of a core constant expression, but evaluation of E would evaluate

• an operation that has undefined behavior as specified in Clause 16 through Clause 33,
• an invocation of the va_start macro (17.13.2 [cstdarg.syn]), or
• a call to a function that was previously declared with the noreturn attribute (9.12.11 [dcl.attr.noreturn]) and that call returns to its caller, or
• a statement with an assumption (9.12.3 [dcl.attr.assume]) whose converted conditional-expression, if evaluated where the assumption appears, would not disqualify E from being a core constant expression and would not evaluate to true. [ Note: .... ]

CWG 2023-07-14

As an alternative, all of 9.12 [dcl.attr] could be added to the "library undefined behavior" bullet. However, CWG felt that a case-by-case consideration is warranted, given that assumptions set precedent in requiring special treatment.

Possible resolution (reviewed by CWG 2023-08-25) [SUPERSEDED]:

Split into a separate paragraph and change 7.7 [expr.const] paragraph 5 as follows:

• ...
• an operation that would have undefined behavior as specified in Clause 4 [intro] through Clause 15 [cpp], excluding 9.12.3 [dcl.attr.assume] and 9.12.11 [dcl.attr.noreturn]; [ Footnote: ...]
• ...

It is unspecified whether E is a core constant expression if E satisfies the constraints of a core constant expression, but evaluation of E would evaluate

• an operation that has undefined behavior as specified in Clause 16 through Clause 33,
• an invocation of the va_start macro (17.13.2 [cstdarg.syn]), or
• a return statement in a function that was previously declared with the noreturn attribute (9.12.11 [dcl.attr.noreturn]), or
• a statement with an assumption (9.12.3 [dcl.attr.assume]) whose converted conditional-expression, if evaluated where the assumption appears, would not disqualify E from being a core constant expression and would not evaluate to true. [ Note: .... ]

Proposed resolution (approved by CWG 2023-07-14) [SUPERSEDED]:

Split into a separate paragraph and change 7.7 [expr.const] paragraph 5 as follows:

It is unspecified whether E is a core constant expression if E satisfies the constraints of a core constant expression, but evaluation of E would evaluate

• an operation that has undefined behavior as specified in Clause 16 through Clause 33,
• an invocation of the va_start macro (17.13.2 [cstdarg.syn]), or
• a return statement in a function that was previously declared with the noreturn attribute (9.12.11 [dcl.attr.noreturn]), or
• a statement with an assumption (9.12.3 [dcl.attr.assume]) whose converted conditional-expression, if evaluated where the assumption appears, would not disqualify E from being a core constant expression and would not evaluate to true. [ Note: .... ]

[Accepted as a DR at the November, 2023 meeting.]

Subclause 9.12.11 [dcl.attr.noreturn] paragraph 2 specifies:

If a function f is called where f was previously declared with the noreturn attribute and f eventually returns, the behavior is undefined.

Undefineed behavior is, in general, detected during constant evaluation, thus requiring an implementation to actually support the noreturn attribute, such as in the following example:

  [[noreturn]] constexpr void f() {}
  constexpr int x = (f(), 0);

It might be desirable to treat the assume and noreturn attributes alike in that regard.