On Fri, 27 Jan 2023 at 12:44, Jonathan Wakely wrote:

> Typo: vocabolary
>

Also:

> *There is absolutely no reason why the above shouldn’t compile.* std::
string and lib::string_view are perfectly compatible, with my::string_view
representing

"my" should be "lib" here, I think.

I've wondered before whether it would help to add a
std::basic_string::view() member to return a string view, which can be more
convenient than an explicit cast to std::string_view, or in the general
case, to std::basic_string<C,T>.

That could allow the

lib::very_useful_algorithm(str);

example to be written as:

lib::very_useful_algorithm(str.view());

(Assuming that lib::string_view is constructible from std::string_view,
which seems reasonable if std::string_view is our vocabulary "non-owning
string" type).

Because neither Option 1 nor Option 2 actually fixes that example. It would
either need the author of lib::string_view to opt-in to the new trait, or
to clone the std::string_view range constructor with all its constraints
and conditional explicit-ness. I don't think it's reasonable to say that
every string-like type should have to copy all the complexity of
std::string_view (and this range constructror is the most complex one, so
even just copying *that* constructor seems unreasonable to expect from
every string-view-like type). Whereas making it easier to get a
std::string_view from a std::string benefits any string-like type that is
interoperable with std::string_view, whether it clones the entire
std::string_view constructor API or not.

So while I'm not opposed to Option 2 as a potential improvement to
std::string_view, I don't think it's necessarily the right way to fix this
example or to help users' own string-like types.