>
> 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 :]>{};
> }
> ```
> 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.
>

Yes, but this is by design. meta::info objects as function parameters
belongs to (just like other functions parameters) the evaluation-time
world, not instantiation-time. Indeed metaprogramming with the meta::info
proposal implies that, if the output of your metaprogramming algorithm
depends on the type of your reflection, then it must return something which
must then be injected in the context where that value is an
instantiation-time construct.

This does not defeat the purpose of operating over uniformly typed values.
For example, imagine a meta-function which generates the code needed to
serialize any value. With the meta::info proposal, the whole meta-function
never needs to be instantiated, simply evaluated, and then the returned
fragment is injected (a task essentially equivalent to instantiation) into
the caller's context.

With your proposal, since the meta-objects are uniquely typed, any
functions using them must be instantiated upon use. This is the major
difference between the two approaches.

In the end, there are no fundamental differences between the possibilities
arising from the two proposals (though of course P2320 goes a lot further
with the ability to inject/reflect functions fragments, top-level
statements, etc) : I can wrap P2320 in a TMP-style API and I can wrap the
reflection TS in a meta::info style API by using type-erasure (since this
is now supported at compile-time in C++20), the only thing is that the
reflection TS always has to perform some kind of template instantiation for
every operation.

This is of course great and necessary work. However I think calling it
"more useful and powerful" than (the specification of) P2320 is incorrect —
and that the opposite is closer to the truth.

(still, I'm curious to see what the meta-algorithms will look like)

Thanks for working on this,
-Jean-Baptiste

Le mer. 8 déc. 2021 à 19:46, Matus Chochlik via SG7 <sg7_at_[hidden]>
a écrit :

> > consteval auto unreflect_type(meta::info mo) {
>
>> > return std::type_identity<typename [: mo :]>{};
>> > }
>>
>> I'm going by memory so I may get something wrong,
>> but when I played with this, even something like
>>
>> consteval bool is_const( meta::info info )
>> {
>> return std::is_const_v<[: info :]>;
>> }
>>
>> didn't work. Note that this doesn't vary the return
>> type.
>>
>> This means that all the consteval primitives like
>> is_const have to be supplied by std, users can't write
>> their own.
>>
>> I don't however remember whether this was a
>> limitation of the reference implementation, or of
>> the underlying model.
>>
>
> Clang's AST transforms and the integral expression evaluators are still
> mostly like wonderland to me ;) but I think that this is a fundamental
> problem of template arguments not being able to depend on the values of
> consteval parameters.
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>