On Wed, Dec 8, 2021 at 7:21 PM Matus Chochlik <chochlik_at_[hidden]> wrote:

> Hi,
>
> On Wed, Dec 8, 2021 at 6:52 PM Jean-Baptiste Vallon Hoarau via SG7 <
> sg7_at_[hidden]> 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
>