On 09/02/2026 23:09, Alejandro Colomar via Std-Proposals wrote:
> Hi Frederick,
>
> On 2026-02-09T13:12:57+0000, Frederick Virchanza Gotham via Std-Proposals wrote:
>> On Sun, Feb 8, 2026 at 6:34 PM Arthur O'Dwyer wrote:
>>
>>> Now, sure, "ignorable attributes" is the law of the land, on paper,
>>> for now; but I don't think it's completely unreasonable for a std-proposals
>>> thread to imagine the future world where the law of the land has changed,
>>> not just for existing standard attributes like [[no_unique_address]] which are
>>> not ignorable, or existing vendor-specific attributes like [[gnu::section("foo")]],
>>> but for all attributes equally.
>>
>>
>> For unignorable attributes, maybe have [[[attrib]]] or [[<attrib>]]
>> or [[(attrib)]]
>
> I'm working on non-ignorable attributes in ISO C2y. There seems to be
> some consensus being built (but not yet there) that non-ignorable
> attributes should be scoped ones (similar to vendor ones), just with
> a standard prefix. I think the best prefix would have to be either
> [[::attr]] or [[std::attr]].
>
>
> Have a lovely night!
> Alex
>

I'm left wondering what would be the disadvantage of simply making
current non-prefixed attributes non-ignorable in C2y? Users don't want
compilers to ignore their attributes, except in two circumstances. One
is for compiler-specific attributes when using a different compiler, and
the other is if you want to use an attribute even though some compilers
might not support it yet.

Let me leave compiler-specific namespaces until further down.


Consider the current standard attributes. Most of them are either
related to diagnostics, or to optimisations. Those are inherently
implementation-dependent (including compiler flag dependent) - and a
possible implementation is "do nothing special". Declaring that these
are /not/ ignorable therefore changes nothing for compilers, except for
any compiler that does not support them today. The fix is easy - C2y
conformance should require support for [[noreturn]], [[likely]], and so
on - but "do nothing" is a valid implementation.

Then there are attributes that matter - such as [[no_unique_address]].
Ignoring these means (potentially) breaking code. So these should not
be ignorable. A compiler that can't handle such attributes in a correct
manner (in this case, "correct" meaning matching the platform ABI)
should throw a hard error. (It's __has_cpp_attribute will expand to 0
here, for use in unusual code that can handle a missing implementation.)

The only remaining non-prefixed attributes you could see in code are
spelling mistakes, and these should also not be ignorable.


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


For compiler-specific attributes, it's more complicated. When you are
using the compiler that matches the namespace, it's very much up to the
compiler - everything is, by definition, implementation-dependent. But
it's a different matter for "foreign" namespaces. Again, sometimes
these matter semantically and sometimes they don't. But they /always/
matter to the programmer. And sometimes compilers can implement
particular foreign attributes, sometimes they can't.

While we can expect compilers to support all standard attributes (even
if that support may mean doing nothing or giving an error message), we
cannot expect compilers to recognise all attributes from other
compilers. So we need some kind of new syntax to say that an attribute
can be ignored, or that it must not be ignored, or that it gets default
handling (which today must mean ignorable for compatibility, but may be
controlled by compiler flags). And I think a key point is to be able to
specify choices of attributes. So my suggestion is :

[[comp::attr]]
Ignorable or non-ignorable according to the implementation (with the
recommendation that it is ignorable by default but that the compiler
provide a flag to make it non-ignorable).

[[[comp::attr]]]
Non-ignorable. If a compiler cannot support this in the manner intended
by the "comp" compiler, it is a fatal error.

[[(comp::attr)]]
Ignorable. Compilers are encouraged to provide a warning if they are
the owner of the "comp" namespace and do not recognise "attr".

[[[comp1::attr1 || comp2::attr2 || ... ]]]
Non-ignorable. Compilers must support and apply one of these
attributes, but may choose which. If they cannot support any, it is a
fatal error. For example, [[[gnu::always_inline || msvc::forceinline]]]

[[(comp1::attr1 || comp2::attr2 || ... )]]
The compiler can apply its choice of one of these attributes, but can
ignore them all.

[[comp1::attr1 || comp2::attr2 || ... ]]
This should work like [[[ || ]]]


Global namespace (or std:: namespace, which would be equivalent)
attributes can be included in the same way, and support the [[[ ]]], [[(
)]]] variants as well as the "or" list versions. The only difference is
that I would want to see [[ ]] default to non-ignorable for standard
attributes.


David