Yes, compilers can give warnings and errors far beyond the requirements
of the standards with the right flags, and I do use these.
Unfortunately, there are a good many programmers out there who think
"it's only a warning, I can ignore it", and regularly don't even enable
the minimum of warnings. I am not looking for ways to improve my own
code or how it is checked - I am trying to think how C++ can make it
harder for /anyone/ to write incorrect code. And I am trying to wrap my
head around the idea that we can have this whole section of the C++
language, with all its potential usage and convenience, but it has been
crippled by the concept that all attributes are ignorable.

In the C++14 standard, we have :

"For an attribute-token not specified in this International Standard,
the behaviour is implementation-defined."

This basically lets compilers make their own choices about how to deal
with scoped attributes (their own ones and "foreign" ones), as well as
supporting back-porting of future standard attributes. But they have to
handle standard-defined attributes in the way the standard says (with
the leeway allowed). Good stuff.


In C++17 onwards, we have :

"For an attribute-token not specified in this International Standard,
the behaviour is implementation-defined. Any attribute-token that is
not recognized by the implementation is ignored."

And now we suddenly have a cop-out clause saying even the standard's
definitions can be ignored.


What exactly am I expecting? I don't know, really. I think perhaps I
was hoping to understand the point of attributes being ignorable, but I
have failed so far. I was hoping perhaps that there could be a way to
get more user control about ignorability, but I think my suggestions are
a long way from being generally acceptable. I appreciate that some
people will want attributes, or at least some of them and some of the
time, to be ignorable - that's no problem to me. I'm in favour of user
control here. But by saying attributes are always ignorable, you are
telling programmers that part of their code may be worthless, and
throwing away an excellent way of adding new features to the language
without the usual massive (but necessary) discussions about new keyword
names, backwards compatibility, vexing parses, and other challenges.

I am not, however, expecting anything to change in the immediate future.
  At best, I might have encouraged some people to think a little more
about the consequences of ignorable attributes and consider possible
modifications to that rule.



On 13/02/2026 11:48, Simon Schröder wrote:
> I'm not sure what exactly you are expecting. With the proper compiler
> flags unknown (or mispelled) attributes give a warning and then you can
> even turn on warnings as errors. If you want to force all compilers to
> support vendor-specific attributes from other vendors you have to put
> those into the standard. I personally like to write portable C++ code
> which is why you will never get all people to agree on non-ignorable
> attributes.
>
> As long as you are using GCC-specific attributes and the GCC as
> compiler, it would be quite stupid for GCC not to respect their own
> attributes. But, this is a problem of GCC and not of the standards
> committee. If you are relying on compiler-specific extensions, go to the
> compiler vendor. I don't think that any sane compiler will ignore
> certain attributes only sometimes. I expect compilers to be consistent
> in this respect. And if they are not, I don't want to use that compiler
> (or maybe just not that attribute). With this in mind, I don't see why
> we need to force non-ignorable attributes. Would it help if the standard
> required that each compiler makes their own vendor-specific attributes
> non-ignorable?
>
> On Fri, Feb 13, 2026 at 11:34 AM David Brown via Std-Proposals
> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> wrote:
>
> 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] <mailto: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]
> <mailto:std-proposals_at_[hidden]>;
> > *CC:* David Brown <david.brown_at_[hidden]
> <mailto: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]
> <mailto: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]
> <mailto:Std-Proposals_at_[hidden]>
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
> >
> >
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>