[defns.undefined] Fix the note on undefined behavior in constant evaluation

[frederick-vs-ja]

Currently, the assmue and noreturn attributes are allowed to bring undefined behavior into constant evaluation. There might be more such standard attributes in the future.

(Attempted to fix) #7042.

[jensmaurer]

No, that's not the intent. We want that rule "never undefined behavior in constant evaluation" to hold. We do have special rules for the mentioned attributes; see [expr.const] p6.3 and p6.4.

[frederick-vs-ja]

We do have special rules for the mentioned attributes; see [expr.const] p6.3 and p6.4.

The original issue was exactly concerned about these special rules. Is there better way to mention these exceptions in the note?

[jensmaurer]

Your claim was "Currently, the assmue and noreturn attributes are allowed to bring undefined behavior into constant evaluation."

I pointed to the text where that claim is refuted: We continue not to have UB in constant evaluation; we just sometimes make that evaluation not a constant evaluation anymore. In particular, a returning [[noreturn]] function is not UB in constant evaluation; it just keeps going (unless detected).

[frederick-vs-ja]

In particular, a returning [[noreturn]] function is not UB in constant evaluation; it just keeps going (unless detected).

So is the intent that when returning from a [[noreturn]] function happens to be allowed in the evaluation of some constant expression, UB is not considered happening?

[jensmaurer]

That's my understanding: If a [[noreturn]] function returns in constant evaluation, it's either no longer constant evaluation (if your compiler detects that), or it's as-if [[noreturn]] were absent. This is consistent with the idea that attributes can be ignored.

[frederick-vs-ja]

That's my understanding: If a [[noreturn]] function returns in constant evaluation, it's either no longer constant evaluation (if your compiler detects that), or it's as-if [[noreturn]] were absent. This is consistent with the idea that attributes can be ignored.

Oh I see. Then perhaps we should clarify [[noreturn]] and [[assume]] never bring UB into constant evaluation instead.

But this isn't what [dcl.attr.assume] and [dcl.attr.noreturn] currently say. Related UB is not excluded from constant evaluation, which seemingly allows constant expression to have arbitrary result when the restrictions are violated. Should there be a CWG issue?

[frederick-vs-ja]

CWG2924

Closing as the clarification doesn't seem editorial.