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