Matus Chochlik wrote:
> > vector<info> can't be replaced with span<info> though because it's
> > often built dynamically (e.g. if the contents are filtered with a predicate.)
>
> This still happens at compile-time inside of the compiler, so it could allocate the
> filtered range of metaobjects by using some internal mechanism, that is not
> exposing generic "dynamic" allocation in consteval.

If all the consteval functions manipulating or returning vector<info> are
compiler built-ins, then yes, that would be possible.

I think the motivation to use vector<info> (and extend the language to make
this possible) was to enable (at least some of) these functions to be written in
C++.

In contrast, I can't think of a case where a string returned by these facilities
isn't produced by the compiler.

(I also hit this limitation when I tried to implement Boost.Describe-like
primitives on top of 2320, which return the reflection metadata in types,
rather than values. It's not possible to go from std::string to that.
vector<info> is however fine as long as range splicing it works.

Although as I'm writing this it occurs to me that I can range-splice a std::string
too, which might enable me to obtain a char const* from it, after all. :-) )