On Wed, Dec 8, 2021 at 7:21 PM Matus Chochlik <chochlik@gmail.com> wrote:
Hi,

On Wed, Dec 8, 2021 at 6:52 PM Jean-Baptiste Vallon Hoarau via SG7 <sg7@lists.isocpp.org> wrote:
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.
 
I'm still debugging and finishing the implementation, but I plan to write at least some of these; today I did a simple UML-generator:
https://github.com/matus-chochlik/llvm-project/blob/reflection/_reflexpr/mirror04.cpp

It will be available on CE tomorrow, for now you can see the result here:
https://twitter.com/matus_chochlik/status/1468556508761837574

 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?

Besides the thing that Peter mentioned in another response, something like this didn't work either when I played with the meta::info implementation:
```
auto unreflect_type(meta::info mo) {
  return std::type_identity<typename [: mo :]>{};
}
```
Sorry I omitted consteval, this should have been: 
consteval auto unreflect_type(meta::info mo) {
  return std::type_identity<typename [: mo :]>{};
}
 
i.e the return type cannot depend on a non-template meta::info value. You basically have to create a separate consteval function that creates and returns the metaobject. This limits how the metaobjects are passed around in a composition of metaprogramming algorithms. You probably can work-around this by making all the metaprogramming algorithms templates, but is sort-of defeats the thing where all metaobjects are of a single type (meta::info) and In the end it's almost the same as what the "mirror" header does.

--Matus