Date: Tue, 10 Feb 2026 14:06:10 +0200
On Tue, 10 Feb 2026 at 13:47, Jan Schultke <janschultke_at_[hidden]> wrote:
>
>
>> Since when is the existing always_inline a mere hint? And since when
>> is it a request that emits a mere warning if the compiler fails to do
>> what it's told
>> to do by that attribute? I mean other than for indirect calls.
>
>
> [[gnu::always_inline]] is treated as an ignorable hint by Clang. See https://godbolt.org/z/exTed6zWY See https://clang.llvm.org/docs/AttributeReference.html#always-inline-force-inline Maybe there is a way to get Clang to issue a warning when [[gnu::always_inline]] is being ignored; it seems like failure is being silently swept under the rug.
>
> GCC issues an error when it fails to inline with [[gnu::always_inline]] applied.
Indeed. So making it ignorable would be just a bad choice.
>> Could we perhaps not reinvent the existing attributes with the same
>> spelling but with a different meaning?
> Making the attributes ignorable hints would be consistent with Clang, so it's standardizing existing practice.
The worst practice possible. Choosing that would be just silly.
> It's also similar to how constinit works (https://eel.is/c++draft/dcl.constinit#2). constinit is stated to make the program ill-formed when dynamic initialization happens, without imposing any change in semantics to initialization (e.g. making things constant-evaluated that otherwise wouldn't be). It's just a means of diagnosing accidental dynamic initialization, just like, say, a standard [[nrvo]] would diagnose an accidental failure to perform NRVO.
constinit is not at all what you describe. It's intentionally and by
design not an attribute precisely because it's not a diagnostics tool,
it's a facility for semantic enforcement.
> Of course, one of these results in an error and the other in a warning, but there's really no reason why we couldn't have had a [[constinit]] attribute in that style, and you could achieve the same effect using -Werror=... after all.
And that doesn't work, because not everybody compiles with -Werror,
but every single user wants a constinit variable to be actually
constant-initialized
or otherwise ill-formed.
>
>
>> Since when is the existing always_inline a mere hint? And since when
>> is it a request that emits a mere warning if the compiler fails to do
>> what it's told
>> to do by that attribute? I mean other than for indirect calls.
>
>
> [[gnu::always_inline]] is treated as an ignorable hint by Clang. See https://godbolt.org/z/exTed6zWY See https://clang.llvm.org/docs/AttributeReference.html#always-inline-force-inline Maybe there is a way to get Clang to issue a warning when [[gnu::always_inline]] is being ignored; it seems like failure is being silently swept under the rug.
>
> GCC issues an error when it fails to inline with [[gnu::always_inline]] applied.
Indeed. So making it ignorable would be just a bad choice.
>> Could we perhaps not reinvent the existing attributes with the same
>> spelling but with a different meaning?
> Making the attributes ignorable hints would be consistent with Clang, so it's standardizing existing practice.
The worst practice possible. Choosing that would be just silly.
> It's also similar to how constinit works (https://eel.is/c++draft/dcl.constinit#2). constinit is stated to make the program ill-formed when dynamic initialization happens, without imposing any change in semantics to initialization (e.g. making things constant-evaluated that otherwise wouldn't be). It's just a means of diagnosing accidental dynamic initialization, just like, say, a standard [[nrvo]] would diagnose an accidental failure to perform NRVO.
constinit is not at all what you describe. It's intentionally and by
design not an attribute precisely because it's not a diagnostics tool,
it's a facility for semantic enforcement.
> Of course, one of these results in an error and the other in a warning, but there's really no reason why we couldn't have had a [[constinit]] attribute in that style, and you could achieve the same effect using -Werror=... after all.
And that doesn't work, because not everybody compiles with -Werror,
but every single user wants a constinit variable to be actually
constant-initialized
or otherwise ill-formed.
Received on 2026-02-10 12:06:25