On 10/02/2026 13:15, Alejandro Colomar wrote:
> Hi David,
>
> On 2026-02-10T11:28:08+0100, David Brown wrote:

<snipping a bit for brevity>

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

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?

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


>
> Have a lovely day!
> Alex
>