On 13/02/2024 16.10, Gabriel Morin via SG14 wrote:
> I don't see attributes and reflection as mutually exclusive, on the contrary, they should work hand-in-hand. For tag-based code generation, you need some way of adding metadata to your classes/members/functions/etc, and custom attributes fit the bill perfectly - if you could use them in a multi-platform, multi-compiler setting without getting warnings or disabling all attribute validation, that is.
>
> That's how custom attributes are used in C#. <https://learn.microsoft.com/en-us/dotnet/csharp/advanced-topics/reflection-and-attributes/accessing-attributes-by-using-reflection> You tag something with them, then use reflection to discover the attribute and use the metadata however you want.

> But now that you mention it, I don't see any mention of attributes in P2996R1 <https://github.com/cplusplus/papers/issues/1668>. It seems like a missed opportunity, as merely discovering the presence of an attribute and getting its parameter(s) shouldn't add a lot of complexity, when you already support enumerating members <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2996r1.html#selecting-members>.

If we permit inspection of attributes via reflection, the next step is that
people will want to define a zoo of their own attributes for inspection.

So far, attributes are defined by compiler vendors or similar, not by user
programs. I think I want to see some exploration of the design space here
before we entertain that direction. (For example, do custom attributes have
to be declared? Should there be a type system for the attribute-argument-clause?
Should such user-defined annotations use an annotation mechanism distinct from
attributes to start with? What's the answer when two disjoint libraries try
to introduce the same attribute for different purposes?)

Jens



> Le lun. 12 févr. 2024, à 11 h 56, Henry Miller <hank_at_[hidden] <mailto:hank_at_[hidden]>> a écrit :
>
> (ignoring the other email about P3132 likely being DOA as attributes mostly already work this way if the syntax errors were fixed - though that is a good point).
>
> I think you are on the wrong track to use attributes for P3132. It seems like reflection is a better answer for what you are really trying to do here. Reflection should allow you to replace all your custom built tools with C++ that the compiler just uses to build the right code. Now granted reflection isn't done yet, and I'm not following it closely enough to know how it works, but it seems to me that you should contact the reflections group and see how they would handle all your motivating examples.
>
> The only downside of reflection once we have it is you have to write a lot of code to take advantage of reflection, while you already have well testing programs that could easily be modified to understand whatever attributes you care to add. However long term it seems like the better approach.
>
> --
> Henry Miller
> hank_at_[hidden] <mailto:hank_at_[hidden]>
>
> On Mon, Feb 12, 2024, at 06:04, Patrice Roy via SG14 wrote:
> > Hi everyone!
> >
> > As mentioned in a previous email, I cannot be present at the SG14 meeting
> > next Wednesday due to... giving a C++ class to SG14 people at the same time
> > :/
> >
> > Still, following the efforts listed as «papers to come soon» in P2966 last
> > year, there will be two papers in the next WG21 mailing destined for Tokyo.
> > They are currently in «draft» status in the ISO papers system:
> >
> > * P3132 Accept attributes with user-defined prefixes
> > * P3134 Attribute [[asserts_rvo]]
> >
> > P3132 aims to make it easier to do tooling through user-defined attributes
> > and has a number of additional upsides.
> >
> > P3134 aims to provide guarantees that a function's implementation can make
> > it possible for appropriately written calls to that function to lead to the
> > return value optimization
> >
> > Please don't mind the formatting too much, I know it's perfectible. Both
> > are relatively short papers.
> >
> > You will find copies (with P numbers, but they will only really be P papers
> > after the SG14 meeting) attached to this email. If you would be so kind as
> > to (a) take a look at them, and ideally (b) provide suggestions /
> > constructive criticism on this list or at the SG14 meeting this week, I
> > would integrate this feedback into the official papers. In particular, I
> > get the impression that the audience should be LEWG but I'd be open to
> > knowing what the groups thinks.
> >
> > Thanks everyone!
> >
> > _______________________________________________
> > SG14 mailing list
> > SG14_at_[hidden] <mailto:SG14_at_[hidden]>
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg14 <https://lists.isocpp.org/mailman/listinfo.cgi/sg14>
> >
> > Attachments:
> > * P3132 Accept attributes with user-defined prefixes.pdf
> > * P3134 Attribute asserts_rvo.pdf
>
>
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14