Hi David,

On 2026-02-10T17:13:30+0100, David Brown wrote:
[...]
> > > > > [[[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 '['
> >
>
> (The third [ was for consistency with user indication that the attribute
> should not be ignorable, but that's an orthogonal point.)

[...]
> > > 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
> >
>
> While that is all true, it defeats the point of attributes (at least
> non-standard attributes) in the first place. After all, why support
> [[gnu::cold]] or [[msvc::cold_func]] (if that existed) format when you could
> have simply written :
>
> #if defined(__GNUC__)
> # define COLD __attribute__((cold))
> #elif defined(_MSC_VER)
> # define COLD _declspec(cold_func)
> #else
> # define COLD
> #endif
>
> COLD void f(void);

The point of [[]] is that attribute placement was a mess before standard
attributes. [[]] guarantees that people will know what an attribute in
that place means.

> Compiler-check conditional compilation and conditional macro definitions are
> horrible. Conditional compilation and macro definitions based on feature
> checks are marginally less horrible, but only marginally so. Both can be
> very useful, but you don't want to have to use them except in rare and
> unusual cases. It is far better to be able to write :
>
> [[gnu::cold, msvc::cold_func]] void f(void);
>
> and skip the pre-processor stuff.

If you're going to annotate your functions with attributes, I'm pretty
sure you won't do this. Existing projects should that this is not how
people do it (at least, the ones I've seen).

> Even better, IMHO, would be to be able to
> write :
>
> [[[gnu::cold || msvc::cold_func]]] void f(void);
>
> and know that the compiler will complain if it can't make the function cold
> in one way or the other.
>
>
> Good language syntax decisions make it easy to write common constructs,
> middle-of-the-road convenience for rare constructs, and don't care if it is
> awkward or verbose for very niche cases. We want keywords for things people
> want often, attributes for things that turn up occasionally, and can leave
> ugly conditional compilation for rarities or when compiler developments are
> ahead of language standardisation.

I'd say most of the function prototypes I write have an attribute. And
if you look at the glibc headers, virtually all of them do.
Attributes are less common than qualifiers, but not by far.


Cheers,
Alex

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