Hi David,

On 2026-02-10T11:28:08+0100, David Brown wrote:
> 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.

I fully agree on this part. And in fact, I suggested exactly that in
a mail in WG14. Nobody accepted that. :/

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

Also agree. WG14 dismissed those concerns.

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

Agree.

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

I think it's a bad idea to allow programmers to decide about the
ignorability of language features. Ignorability of a feature should be
part of the feature itself. What would it mean to do

 [[(gnu::packed)]]

? That's an ABI-breaking attribute, and ignoring it will result in
bugs.

I prefer keeping all vendor attributes non-ignorable, and close the door
to ignorable vendor attributes. Then, if we want standard non-ignorable
ones, let's just specify a standard "vendor"; that could be the empty
prefix ::, or maybe std::.


Have a lovely day!
Alex

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

-- 
<https://www.alejandro-colomar.es>