One of the issues that arise is header dependencies… do we really want to require that <vector> and <string> be included for any code that does something nontrivial with reflections? Maybe “yes”, and maybe that’ll be less of a concern with modules?

Meanwhile, our (Faisal & I) current implementation uses std::string_view (with some assumptions about its internal structure) and a very simple vector<info>-like class that’s part of the <meta> header.

 Daveed


> On Apr 9, 2021, at 8:57 AM, Peter Dimov via SG7 <sg7_at_[hidden]> wrote:
>
> Hana Dusíková wrote:
>> 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 :)
>
> That's not a problem because you can always store the result in a std::string.
> The advantage of returning `char const*` is that you can always get either
> string or string_view from it without any trouble. You can also obtain a string
> from a string_view (but not `char const*` from a string_view.)
>
> It does introduce some slight inconvenience in the case you just want to
> concatenate using + though.
>
>> 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
>
>
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7