On 13/02/2026 13:39, Sebastian Wittmeier via Std-Proposals wrote:
> 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)
>

Ah, okay. That makes more sense to me now! And you are absolutely
write that there is a similarity here.

> /*! \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.
>

I do think there needs to be a distinction between the core purpose of
C++ as a programming language, and additional tools.

> 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.

I am quite convinced the answer is that we /do/ need something that is
basically like today's attributes, but not ignorable. However, I am
very much open to the idea that this could be "something like
attributes" rather than attributes.

Call them "characteristics", and use smiley brackets - (-: ... :-)


It might also be nice if tools like doxygen and Code Sonar started
having [[dox:: ]] and [[sonar:: ]] attributes. Even better would be an
independent body defining [[lint:: ]] attributes that Code Sonar,
Coverity, and others could use (with gcc and clang supporting what they
can). That would hugely benefit developers who want to use multiple
tools. And yes, those would /definitely/ be ignorable by other tools!

>
> You gave a lot of arguments in favor in your post.

I feel sometimes I have been ranting, rather than presenting arguments.
And I hope it is clear that while I feel attributes should, by default,
be non-ignorable, I understand that other people feel differently (even
if I am not sure I understand all their reasons).

David

>
> -----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
> >
> >
>
>