On 13/02/2026 07:03, Simon Schröder via Std-Proposals wrote:
>
>
>> On Feb 10, 2026, at 8:06 PM, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> On Tuesday, 10 February 2026 10:55:23 Pacific Standard Time Alejandro Colomar
>> via Std-Proposals wrote:
>>> But [[comp::attr]] has never been ignorable. That ship has not sailed
>>> yet.
>>
>> Yes they have and are. If I put a [[gnu::noclone]] attribute on a function and
>> compile with Clang, it just tells me:
>>
>> warning: unknown attribute 'gnu::noclone' ignored; did you mean
>> 'gnu::noinline'?
>>
> One good thing about C++ is that its source code can be portable in general. If we require that vendor specific attributes cause a compiler error we are forced to use macros instead. Sure, we might not be able to link to a library compiled with a different compiler that supports the attribute. But, as long as we compile everything with the same compiler, it should work (in 99% of the cases) even if we ignore attributes. We cannot require that msvc supports all gnu attributes whenever new ones are introduced. In order to avoid this we have a standard to define all attributes that should (but don’t have to) be supported by every compiler. I believe that it is sufficient to provide a diagnostic for foreign attributes and not apply them.

For many attributes, ignoring them on compilers that don't support them
is safe - a lot of attributes (standard or vendor-specific) are for
improved static error checking. Another lump are for optimisation. But
there are also attributes that directly affect semantics and the
generated code or data structures. If a compiler fails to handle these,
the result is code that does not do what the programmer intended. If
the programmer has used "[[gnu::interrupt]]", or "[[gnu::ms_abi]]" on a
function, and a compiler ignores it, the result is broken code -
probably silently broken until weird effects at run-time lead to
complete disaster. The only really correct handling of these attributes
on a compiler that does not support them is a fatal compile-time error.
(The same applies to misspellings of such attributes.)

I am really not happy about the attitude of ignoring attributes. I
don't write code just for the fun of it - if I put something in my code,
I expect the compiler to pay attention to it. If I have written
something that the compiler can't understand or can't implement, I
expect it to tell me. I am fine with having a way for the programmer to
explicitly tell the compiler that an attribute can be ignored, but the
default should not allow ignoring them. 99% of cases being okay is 1%
of cases being disaster.


As things stand with C++ today, compilers are left to fix this
"ignorable attributes" flaw (IMHO) that has crept into the standard.
gcc has both a "-Wignored-attributes" warning (for when the compiler
understands the attribute, but is ignoring it) and a "-Wattributes"
warning (for when the attribute is unknown - including other
vendor-specific attributes). These are both enabled by default (albeit
only as warnings, not as fatal errors). This is because the gcc
developers have understood that the C++ standards got this badly wrong,
and ignorable attributes are a severe disservice to C++ programmers.

A quick check with godbolt suggests that most other C++ compilers are
similar, except MSVC that doesn't blink on bad attributes unless you
enable warnings (which of course any sane developer will do).

Even with that, I would recommend that if you are writing code that
relies on vendor-specific attributes, you should use vendor-specific
syntax. If you write "__attribute__(("ms_abi"))" or
"__declspecl("fastcall"))", you are sure to force a compile-time error
if the code is used with a compiler that can't handle it. Of course for
your cross-platform code you'll hide these behind macros and conditional
compilation - but that's you, the programmer, making active choices and
checking things work correctly on those platforms. It is not the C++
standards lying back and saying "It's all cool, don't worry about it,
we'll let that stuff slide".