One possible use case for me is to creating a new name for a reflection and then splice it somewhere. I would rather manipulate with a string using std::string API than using C to control C++ reflection, that would be embarrassing :)

Hana

> On 9. 4. 2021, at 14:46, Peter Dimov via SG7 <sg7_at_[hidden]> wrote:
>
> 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. :-) )
>
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7