Date: Fri, 9 Apr 2021 16:28:46 +0200
On Fri, Apr 9, 2021 at 4:26 PM Peter Dimov via SG7 <sg7_at_[hidden]>
wrote:
> David Vandevoorde 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.
>
> That's another reason I prefer `char const*` - I don't find it elegant when
> compiler built-ins have to know about user-defined types such as
> `string_view`.
>
But I don't think it is necessary for the built-ins to know about
string_view, the builtins are usually wrapped into something that can take
a `const char[N]` from the built-in and turn it into a string view.
wrote:
> David Vandevoorde 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.
>
> That's another reason I prefer `char const*` - I don't find it elegant when
> compiler built-ins have to know about user-defined types such as
> `string_view`.
>
But I don't think it is necessary for the built-ins to know about
string_view, the builtins are usually wrapped into something that can take
a `const char[N]` from the built-in and turn it into a string view.
Received on 2021-04-09 09:28:59