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

Le lun. 12 févr. 2024, à 11 h 56, Henry Miller <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]
>
> 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]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg14
> >
> > Attachments:
> > * P3132 Accept attributes with user-defined prefixes.pdf
> > * P3134 Attribute asserts_rvo.pdf
>