On Fri, Apr 9, 2021 at 4:16 PM David Vandevoorde via SG7 <sg7@lists.isocpp.org> wrote:
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.

This is quite close to what I'd expect from the API, with the minimal-vector-like (doing only what is necessary for consteval) class being a public part of the API.
(+ maybe a guarantee that the underlying strings covered by the string_view is always zero-terminated when returned by reflection)


> On Apr 9, 2021, at 8:57 AM, Peter Dimov via SG7 <sg7@lists.isocpp.org> 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
>>