> On Jan 18, 2022, at 1:49 PM, Barry Revzin <barry.revzin_at_[hidden]> wrote:
>
>
>
> On Tue, Jan 18, 2022 at 12:29 PM Peter Dimov via SG7 <sg7_at_[hidden] <mailto:sg7_at_[hidden]>> wrote:
> > But on the other hand, if you have a `char const*`, it's trivial to obtain a
> > string_view from it, whereas the reverse... isn't.
>
> <source>:9:27: error: 'std::basic_string_view<char>' is not a valid type for a template non-type parameter because it is not structural
> 9 | template<std::string_view sv> consteval auto to_charp()
> | ^~
>
> Yeah :-(
>
> This is actually a good reason to return string and vector<info> instead of string_view/char const* and span<info>. The containers will be usable as non-type template parameters (eventually), but the views will never be, and while char const* could be it's also not as usable.

Yes, but we have a chicken-and-egg challenge there. Currently, you cannot:

 constexpr std::string r = name_of(^S);

because that capability was removed from P0784 in the end.

Unfortunately, that hasn’t made much progress since, and I’m loathe to make reflection hinge on us getting that capability in time.

As always, an extra layer of indirection can help:

 template<info rr> struct Metaprog {
   …
 };

 Metaprog<reflect_value(members_of(^S))> mprog;

However, I’d expect that Metaprog instance to have internal linkage. (Section “A Note About Linkage” in the paper needs updating to cover cases like that.)

 Daveed