There are already a few competing spellings for attributes in the wild.
Some that C++ recognizes (e.g. [[nodiscard]], [[deprecated]], etc.), some
that have some sort of vendor namespace (e.g. [[msvc::forceinline]]), and
some that are spelled entirely differently (e.g. GCC's
__attribute__(expr)-style syntax).

I suspect that reflection on the attributes we have today are useful (e.g.
querying if a function is marked [[deprecated]] or not), so perhaps it
would be easier for compiler authors to simply retain reflection
information as opposed to creating an orthogonal syntax (and adding
reflection support for that also). There may be the added benefit of
unifying how compiler vendors expose compiler-specific
attributes/extensions instead of the various dialects today (which we
typically juggle with macros and pound-defs).

The advantage of a unique syntax is the ability to anticipate vendor and
user namespacing of attribute names in such a way that existing uses are
accommodated. I would suggest that even if the initial proposal doesn't
figure out the entire story, that the group identify a suitable starting
point for the syntax in order to reserve it for future use.

Best,
Jeremy

On Mon, Oct 16, 2023 at 2:46 AM Ville Voutilainen via SG7 <
sg7_at_[hidden]> wrote:

> On Mon, 16 Oct 2023 at 11:20, Peter Dimov via SG7 <sg7_at_[hidden]>
> wrote:
>
> > I used to argue that unknown attributes should be retained in the AST for
> > reflection purposes, but that actually doesn't give us much, so I
> dropped it.
> > Annotations work sufficiently differently in that we don't just want the
> text
> > of the unknown attribute, we want the compiler to evaluate the constant
> > expression and to retain its result in the AST, not its text.
>
> Ah, and then that other implementation vendor will reiterate to us
> that expressions
> in attributes are a serious nuisance for their implementation.
>
> So, instead of hastily deeming attributes unsuitable for this purpose,
> we might re-entertain
> using them, and make sure to specify and agree that there are certain
> kinds of attributes
> that implementation A is not to toss in the wind, and also certain
> attributes that implementation B
> should try to separately recognize as having expressions in them,
> without necessarily reinventing
> the syntax for those things.
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>