Hi Matus,

Do you have an implementation of some commonly requested reflection-based
algorithms? E.g. : automatic serialization, hashing, "pretty print",
classes registration, automatic binary operators generation, this sort of
thing.

 Otherwise it is similar to the meta::info proposal and currently it is
> more useful and powerful because it is not limited by pure consteval
>

Could you clarify what you mean by this? What does this proposal do that
P2320 proposal cannot?

If/when the issues with consteval are fixed (for example the ability to
> change function return type based on the value of a non-template consteval
> argument)
>

I don't think this will ever happen.
Also, unless I am overlooking something, there is no need for that : if the
goal is to produce a value whose type depends on the value of the
reflection, then, assuming the code splicing of P2320, this can be done by
a fragment containing your "meta-algorithm", and injecting it into the
context where the type is known. So in the case of a
enum-to-string function, the consteval function return the fragment
containing the switch, and the runtime function template inject it, see
https://compiler-explorer.com/z/PEb8s8b3M (i forgot how to implement enum
to string on clang-meta, but this illustrate the pattern). In these simple
cases this is largely the same as a template instantiation.

Le mar. 7 déc. 2021 à 09:55, Matus Chochlik via SG7 <sg7_at_[hidden]>
a écrit :

> Hi SG7,
>
> Here are some examples of a new experimental API that is written on top of
> the compiler builtins from the TS implementation:
>
> https://compiler-explorer.com/z/zePhMf9hc
> https://godbolt.org/z/Ka54ETjcs
>
> Because of current limitations of consteval, some things cannot be
> implemented without using some TMP, but TMP is not required (almost at all)
> to use the API by the end-users.
>
> In this API the metaobjects are represented as *values* but they don't
> have a single named type and the operations are implemented as template
> functions. Otherwise it is similar to the meta::info proposal and currently
> it is more useful and powerful because it is not limited by pure consteval.
>
> If/when the issues with consteval are fixed (for example the ability to
> change function return type based on the value of a non-template consteval
> argument) we could turn the now anonymous metaobject types to a single type
> like `meta::info`, add the sequence filtering predicates, code splicing,
> and add support for storing meta-objects in consteval containers, etc. IMO
> without breaking the existing API.
>
> So I have a couple of questions:
> 1) Do we see this as a viable stepping stone toward getting a first usable
> version reflection into the standard that can be extended later or would
> this be OMDB for someone? (if so I'd be interested in some reasoning why,
> except for TMP-bad)
> 2) Should I try to write a paper?
> 3) Would someone be interested in helping with the paper?
>
> BR,
> --Matus
>
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>