Attributes are not the only part of the language which is ignored. The same is true for source code comments. Comments are often used for automatic documentation generation or other annotations.   If 99% of attributes are ignorable, should the 1% be implemented differently (=not as attributes)?   The ignore lists would be quite long, if all 99% of attributes have to be defined as ignorable. If attributes can be marked as either in-place, it is another possible source of error to mark one in the wrong way.   I agree that this situation can be improved a bit, but I disagree that how it is currently done was wrong.   -----Ursprüngliche Nachricht----- Von:David Brown via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 13.02.2026 09:31 Betreff:Re: [std-proposals] Named Return Value Optimisation [[nrvo]] An:std-proposals_at_[hidden]; CC:David Brown <david.brown_at_[hidden]>; 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". -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals