The 99% was not originally (in this discussion) by me. Thank you for putting your arguments clearly together. It helps the discussion.   I did not mean comments for the user, but comments for automated processing, like Doxygen (copied from the docu) /*! \fn int read(int fd,char *buf,size_t count) \brief Read bytes from a file descriptor. \param fd The descriptor to read from. \param buf The buffer to read into. \param count The number of bytes to read. */ or static analyzer hints   // NOLINT //cppcheck-suppress <id> //coverity[<event_tag> : SUPPRESS] //NOSONAR //codeql[...]   and my argument was that there can be parts of the language, which are ignorable, e.g. because they are used by 3rd party tools. And that there was a need to better attach them (e.g. doxygen comments, static analyzer hints) to specific code instead of keeping them in general comments. So ignorable attributes per se had some need and usage. It was not a wrong decision to introduce them. The question is, whether non-ignorable attributes are useful and needed. And whether attributes (with the same/similar syntax) are the best way for it. You gave a lot of arguments in favor in your post.   -----Ursprüngliche Nachricht----- Von:David Brown <david.brown_at_[hidden]> Gesendet:Fr 13.02.2026 11:34 Betreff:Re: [std-proposals] Named Return Value Optimisation [[nrvo]] An:std-proposals_at_[hidden]; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; david.brown_at_[hidden]; Hi, The difference with comments (and code that is disabled by pre-processor conditional compilation) is that the user knows he/she is writing a comment.  There is an obvious difference between : [[nodiscard]] int foo(); and int foo();// Don't throw away the return value here As far as the claimed 99% / 1% split goes, I do not think it is remotely realistic.  I have no statistics to back up any numbers, but I quick scan of a relatively recent project of mine shows 30 uses of vendor-specific attributes.  Of those, two could be ignored at cost to speed rather than code correctness.  (And given that those functions are for turning off power drivers in the event of an emergency, correct but slow code could still mean disaster.)  About five of them are messing around with elf format symbols - ignoring them would lead to link-time errors.  Another eight are used to control inlining - /essential/ inlining due to the way the code works on this embedded system, not just for code efficiency.  There are about 4 "noreturn" attributes, which could be ignored at the cost of poorer code generation and, more importantly, poorer static error checking. I can accept that certain attributes can safely be ignored /sometimes/. If you are writing code that will be distributed in source form and compiled by different people with different tools and settings, then maybe it is acceptable for those other people to see your code as a finished, debugged black box - they don't need static error checking on it.  You only need your [[nodiscard]] and [[gnu::format]] checks when developing the software, not for build-only compilation.  But even then, those attributes must /not/ be ignored when you are doing some compiles - your development compiles. So perhaps the 99% / 1% split /is/ realistic - but the 99% is for attributes that must either never be ignored, or at least not be ignored during development builds. There are attributes that must never be ignored, ever, because they affect semantics, ABIs, data layout, etc.  There are attributes that are for diagnostic and static error checking purposes only, which can be ignored in non-development builds but must not be ignored in development builds.  There are attributes that only affect code efficiency, not code correctness, so they could safely (but annoyingly) be ignored by some tools.  There are attributes that could be safely ignored on some platforms or for some programs, but which affect code correctness in other cases. It is possible that what is really needed here is some concept similar to enforcement policies for contracts - something to distinguish between when it is acceptable to ignore unimplemented attributes or skip the extra static error checks, and when it is not acceptable to do so. But a general "attributes are always ignorable" attitude just makes the whole thing useless.  We've already got comments for that. David On 13/02/2026 09:33, Sebastian Wittmeier via Std-Proposals wrote: > 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 > >