[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 "";
}
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 -
especially since you claim that having a return statement in a
[[noreturn]] function makes "absolutely no sense".

On Sat, Feb 14, 2026 at 10:51 PM Alejandro Colomar via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hi!
>
> Here's another proposal for constraining attributes. This is likely to
> be even less controversial than that of constraining [[reproducible]]
> and [[unsequenced]]. It's worded for C2y, but the concept applies to
> C++ too.
>
>
> Have a lovely night!
> Alex
>
> ---
> Name
> alx-0088r0 - noreturn can't return
>
> Principles
> - Codify existing practice to address evident deficiencies
> - Enable secure programming
>
> And from the old C23 charter:
>
> - Trust the programmer, as a goal, is outdated in respect to
> the security and safety programming communities.
>
> Category
> Earthly demon.
>
> Author
> Alejandro Colomar <alx_at_[hidden]>
>
> History
> <https://www.alejandro-colomar.es/src/alx/alx/std/wg14/alx-0088.git/>
>
> r0 (2026-02-14):
> - Initial draft.
>
> Description
> It makes absolutely no sense to have a [[noreturn]] function
> that contains a return statement.
>
> [[noreturn]]
> void f(void)
> {
> return;
> // would you mind serving me a dose of Nasal Demons?
> }
>
> More work would be needed to make sure that [[noreturn]]
> functions can't return. This is a good start, though. A low-
> hanging fruit.
>
> Prior art
> Both GCC and Clang diagnose --by default--, even in the case
> where the return statement is unreachable.
>
> alx_at_devuan:~/tmp$ cat nr.c
> [[noreturn]]
> void f(void)
> {
> if (0)
> return;
>
> for (;;)
> continue;
> }
> alx_at_devuan:~/tmp$ gcc -S -O3 nr.c
> nr.c: In function ‘f’:
> nr.c:5:17: warning: function declared ‘noreturn’ has a ‘return’ statement
> 5 | return;
> | ^~~~~~
> alx_at_devuan:~/tmp$ clang -S -O3 nr.c
> nr.c:5:3: warning: function 'f' declared 'noreturn' should
> not return [-Winvalid-noreturn]
> 5 | return;
> | ^
> 1 warning generated.
>
> Proposed wording
> Based on N3783.
>
> 6.7.5 Function specifiers
> @@ Constraints, p5+1
> +A function declared with a <b>_Noreturn</b> function specifier
> +shall not contain a return statement.
>
> 6.7.12.7 The noreturn and _Noreturn attributes
> @@ Constraints, p2+1
> +A function declared with a <b>noreturn</b> attribute
> +shall not contain a return statement.
>
> --
> <https://www.alejandro-colomar.es>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals