My proposal was referring to the (much older) Reflection TS 23619. I was unaware of P1240 and P2996 which already addressed my main concern with syntax in Reflection TS. The argument for a single reflection type is sound and not something I had considered, but this does not contradict the main point of my proposal.

I do still believe my point regarding tuples is still valid. P1240/2996 uses a custom scalar type as the "reflection type" and a new splicing syntax to perform operations on this type. While powerful, it comes at the expense of being a completely new language feature, and also seems to have difficulties with functions (due to not having a convenient, "lossless" way to store functions as a type, correct me if I'm wrong).

If constexpr tuples are used instead, no new syntax for dealing with reflection objects is necessary, and existing approaches to tuples will also work for reflection. Due to this library requirement, this also means ^/reflexpr will be unavailable entirely without <reflect> (and <reflect> also includes <tuple>).

On the topic of ^ and reflexpr, I believe a new operator ^ for reflection is unnecessary. The authors of P1240 cite that "with months of practice with implementations that used reflexpr(...) we experienced consistent feedback that that syntax is too “heavy”," but in casual use outside deliberately using reflection, I do not believe its usage to be common enough to justify this change. Apart from not burning additional syntax, reflexpr also has the advantage of being easier to understand for the untrained, and also avoids all discussion of precedence and overloading due to not being an operator.

Best Regards,
Franklin

-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Jason McKesson via Std-Proposals
Sent: Wednesday, January 3, 2024 7:26 AM
To: std-proposals_at_[hidden]
Cc: Jason McKesson <jmckesson_at_[hidden]>
Subject: Re: [std-proposals] Simplified reflection with tuples

On Tue, Jan 2, 2024 at 9:52 PM Franklin Yang via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hello all,
>
> I am not sure if discussion about reflection is still in order. Regardless, I believe the usage is too complicated and the syntax somewhat messy.

There have been a lot of proposals for reflection. Are you
specifically talking about P2996? What about the proposal you're
talking about is "too complicated"? How is the "syntax somewhat
messy?"

Simply declaring something to be a problem isn't as convincing has
providing an argument showing how it is a problem.

> Instead of a dedicated language feature that creates yet another usage for `using`,

I've only skimmed P2996, but I don't see where they created "yet
another usage for `using`". So again, what proposal are you talking
about?

> I propose simply using the existing std::tuple type to hold member information. This not only reduces potential language clutter, but also provides programmers with a more familiar and “C++-like” interface to reflection.

... as opposed to what? And what does "C++-like" mean? If you use a
type's metadata to hold the information, you have to use template
metaprogramming techniques to access and manipulate it instead of
constexpr programming. I would consider the latter to be more
"C++-like" than the former.

> `reflexpr` will return a tuple containing `std::reflect::var`, `std::reflect::lambda`, `std::reflect::func`, `std::reflect::class`, among others, which represent objects. These “meta-types” will each contain their own specific members (e.g. `std::reflect::func` but not `std::reflect::var` may contain `get_parameters()`), and types for variables and classes could be provided through a type alias.

This sort of thing has been considered, and P2996 provides arguments
about why having a single reflection type is preferable. What do you
find unconvincing in those arguments?

> I do not see a need to alter the contents of the current reflection extensions, just how it is organized and presented. With my proposal, all existing meta-object operations shall simply be converted to members of the std::reflect types, except for those which are impractical.
>
>
>
> Any feedback or criticism is appreciated.
>
>
>
> Thanks,
>
> Franklin Yang
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

-- 
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals