Hi David,

On 2026-02-10T15:47:12+0100, David Brown wrote:
[...]
> > > [[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]]]
> > >
>
> You did not comment on this syntax, which I think is the most significant
> new idea in my post. Do you like this idea, or do you have a better
> alternative?

That feature exists:

 #if __has_c_attribute(gnu::packed)
 # define PACKED gnu::packed
 #else if __has_c_attribute(foo::packed)
 # define PACKED foo::packed
 #else
 # error "No support for a packed attribute"
 #endif

 [[PACKED]] void f(void);

I agree that || would be nice for this. I'd make it

[[gnu::packed || foo::packed]]

without a third '['

>
> > > [[(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.
> >
>
> We can't legislate against programmers doing something stupid! And we
> certainly should not limit their abilities to make useful choices just
> because some people might do something silly - at least not when it requires
> an active choice such as this syntax requires. We should of course try to
> reduce the risk of accidental mistakes (which is a big reason, IMHO, that
> making "[[no_discard]]" ignorable is a terrible mistake - an accidental
> misspelling of a language feature should result in an error message, not be
> quietly discarded).
>
> But I think it would be fine for both the C++ standard and compiler
> documentation for namespace attributes to say that certain attributes cannot
> be ignored. If that applied to "gnu::packed", then "[[(gnu::packed)]]"
> would be an error. But programmers should be allowed to mark an attribute
> like "gnu::cold" as ignorable because it does not affect the semantics of
> the program in any way.
>
> > 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::.
> >
>
> There are lots of vendor attributes that can be used today, and that would
> be safe to ignore. I prefer to say that if an attribute is not ignorable
> (either because the user has used [[[ ]]], or because the it is documented
> as never ignorable) then it cannot be ignored by /any/ compiler. That
> requirement puts a lot of pressure on compiler implementations, and I think
> it is best to relieve that pressure by allowing attributes to be ignorable
> when the user knows that is safe.

That feature exists:

 #if __has_c_attribute(gnu::cold)
 # define COLD gnu::cold
 #else
 # define COLD
 #endif

 [[COLD]] void f(void);

I don't see a need for a new spelling.
I don't see a need to ignorable attributes.


Cheers,
Alex

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