On 10/02/2026 11:45, Sebastian Wittmeier via Std-Proposals wrote:
> Just a feedback to the non-prefixed ones:
>
> -----Ursprüngliche Nachricht-----
> *Von:* David Brown via Std-Proposals <std-proposals_at_[hidden]>
>
> So for non-prefixed attributes, I don't see a situation where ignorable
> attributes are ever appropriate - though some can have
> implementation-defined behaviour which is "do nothing".
>
> If currently attributes are ignorable, especially non-prefixed ones
> (i.e. with valid syntax today), they should not suddenly start to be
> hard errors. Otherwise programs need #if conditionals for each use of an
> attribute to test for the C++ standard.
>
>

I don't think there is currently a clear answer to whether attributes
are ignorable or not - and if they are ignorable, why that is the case.
And there certainly is no clear answer as to whether people think it is
(or would be) good or bad if they are ignorable or not. It seems to me
that the idea that attributes are always ignorable has sneaked into the
language using "proof by repeated assertion", despite the fact that we
have also gained standard attributes with semantically vital effects
that would cause program breakage if ignored.

I am also not suggesting that attributes with today's syntax should
suddenly change to being non-ignorable - I am suggesting a syntax to
make the ignorability explicit, with a target of moving the default
towards non-ignorabile. And I am suggesting that there are very few
situations where it is a good thing for a standard attribute to be ignored.

I don't think there is any more or any less justification for
conditional or ignorable use of attributes than for conditional or
ignorable use of any other newer C++ feature or keyword. I can
understand that someone might want to use [[nodiscard]] for extra
checking on compilers that support it, but want to be able to use the
code on compilers that don't support it. I see no reason why that
programmer should expect the non-supporting compiler to silently ignore
the attribute - any more than a non-supporting compiler would silently
ignore the "constinit" keyword. In both cases, you can make a
conditionally defined macro to deal with older or weaker tools. Or you
can demand better from your tool suppliers, and be /happy/ that your
code fails to compile when used on tools that might not do the right
thing as your code intends.

But of course the C++ standards cannot be written according to what /I/
think is the ideal world - they have to treat backwards compatibility
with existing code as a priority. That's why I say existing [[attr]]
syntax has to be treated as before (unless a compiler flag says
otherwise), even though I think the great majority of C++ programmers
would be happier if the attribute were not igorable.