On Tue, Oct 22, 2024, 11:32 AM Peter Dimov via SG7 <sg7_at_[hidden]>
wrote:

> Hana Dusíková wrote:
>
> > And suddenly we are in land of custom reflection annotation (p3394), is
> there
> > a way how integrate these two together?
>
> Many are suggesting this, but I'm not fond of the idea. Annotations are
> static
> markers, decorators are consteval functions manipulating the entity; these
> two
> aren't the same thing and I'd rather not see them integrated.
>

I'm going to change the subject line so that it's at least related to the
topic.

On some level, there are three things that an annotation could do:

* just be static data
* be an observer - it gets called with the (possibly-complete) declaration
and can do validation
* be a mutator - it gets called with the (possibly-complete) declaration
and can mutate it in some way, like by adding more declarations into a
class.

Even in the "just be static data" use-case, we need the other two (see
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3394r0.html#other-directions-we-are-exploring).
Do these different uses merit different syntax? I dunno yet. I don't know
how much I care from the call site, and I've certainly used Python
decorators that themselves just add static data.

Either way leading syntax runs into the same issue as to why annotations
are weirdly in the middle of a class declaration instead of in front:

[[=a]] struct C {} c;

The annotation here applies to the variable c, not the type C. Maybe we
could get away with the decorator syntax by saying you can't decorate
variables.

Barry

>