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@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg7