Thinking outloud, as an example, we might declare:

template <bool>
class Serializable {};

And later use this class as a decorator like so:

struct Foo
{
    @Serializable<true>
    int data;
}:

As an instantiated template type, this attribute upon query could leverate
the same meta syntax/querying proposed in the original paper. It would
support namespaces, nested declarations, and other declaration contexts the
language understands today. In addition, it could borrow the infrastructure
needed for expression evaluation in existing template arguments.

The primary drawback is that this syntax would restrict decorator params to
types that can be passed via NTTP. A string literal isn't an option
currently, for example.

2023년 10월 16일 (월) 오전 3:29, Jeremy Ong <jeremycong_at_[hidden]>님이 작성:

> > In contrast, an (unknown to the compiler) attribute...
>
> I wonder if we should consider the approach used by Typescript decorators
> or C# attributes here. The idea is that the decoration must be imported
> prior to use, such that the compiler understands the decorator shape (param
> types, if any).
>
> 2023년 10월 16일 (월) 오전 3:20, Peter Dimov via SG7 <sg7_at_[hidden]>님이
> 작성:
>
>> Ville Voutilainen 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.
>>
>> They don't seem to mind parsing arbitrary expressions in __declspec,
>> so they could probably think of something. E.g. this all works
>>
>> #define MY_ALIGNMENT 4
>> constexpr int my_alignment = 4;
>> constexpr int calc_align( int x ) { return x*x; }
>>
>> __declspec(align(MY_ALIGNMENT)) int z1;
>> __declspec(align(my_alignment)) int z2;
>> __declspec(align(calc_align(2))) int z3;
>> __declspec(align([](int x){ return x*x;}(2))) int z4;
>>
>>
>> > So, instead of hastily deeming attributes unsuitable for this purpose,
>>
>> "Hastily" -> after thinking about the subject for more than two years.
>>
>>
>> --
>> SG7 mailing list
>> SG7_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>>
>