Hi Matthias,

On 2026-02-15T21:43:03+0100, Matthias Wippich wrote:
> [dcl.attr.noreturn]/2 states
> > If a function f is invoked where f was previously declared with the noreturn attribute and that invocation eventually returns, the behavior is runtime-undefined.
>
> runtime-undefined is defined in [defns.undefined.runtime] as
> > behavior that is undefined except when it occurs during constant evaluation
> with a note saying it's implementation-defined whether an expression
> with such behavior is deemed non-constant.
>
> Therefore, the following code should not be able to exhibit undefined
> behavior despite having a reachable return statement in a function
> with noreturn attribute.
> ```cpp
> [[noreturn]] constexpr int foo() {
> if consteval {
> return 42;
> }
> throw "";
> }

I'd say let's disallow [[noreturn]] in such a thing.

If this ever happens in the real world, I don't think removing the
attribute would be a big issue.

> static_assert(foo() == 42); // impl-defined
> ```
> Curiously, while all of the big 3 accept this code, GCC and Clang emit
> a diagnostic because of the return statement regardless (see
> https://godbolt.org/z/15qhMo7b3 ).
>
> From what I can tell the wording in [dcl.attr.noreturn] got changed
> from "undefined" to "runtime-undefined" during resolution of CWG2924 (
> https://cplusplus.github.io/CWG/issues/2924.html ). If my reading is
> correct this changed the situation in aforementioned code from
> unspecified to implementation-defined.
> Considering that we have since gained constexpr exceptions, noreturn
> does not seem meaningless during constant evaluation to me. I find it
> a bit odd that returning anyway is only UB at runtime.
>
>
> I think the change you propose is interesting, but if pursued for C++
> I would welcome discussion about situations like the aforementioned -

Yup; thanks for pointing this out!

> especially since you claim that having a return statement in a
> [[noreturn]] function makes "absolutely no sense".

-- 
<https://www.alejandro-colomar.es>