On Fri, 27 Jan 2023 at 14:44, Jonathan Wakely via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> > Unless my::string itself provides an implicit conversion operator towards std::string_view,
>
> That was always the intended solution. That's why std::string_view doesn't have a constructor from std::string, but relies on std::string converting to std::string_view instead: because that's the pattern we expected user-defined strings to follow. We can't make std::string_view know about every string type out there, but they can know about std::string_view (because it's in the standard). The range constructor has changed the landscape though.

Right, but it indeed still remains so that we recommend string-like
types and also string-view-like types to provide a conversion
to std::string_view.

> > In Qt, the author implemented the same semantic change of P2499R0 for Qt’s string view classes.
> That was your choice to "break" it in that way, copying std::string_view's constructor overload set isn't required ;-)

Aye. I've been too astonished to comment on the review of that change,
because I was stopped by "*WHY* are we copycatting
that range constructor _at all_, let alone then having to tweak it???" :)