On Fri, 27 Jan 2023 at 12:17, Giuseppe D'Angelo via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hello,
>
> I'm working on a proposal that wants to "make string views usable again"
> as an interface type for read-only non-owning contiguous string data.
>
> Namely: re-enable their implicit conversion from any other compatible
> range class. P2499R0 made the conversion explicit, IMO damaging
> interoperability between string view classes. Applying P2499's change
> (make the range constructor explicit) to Qt's own string view classes
> caused quite some friction.
>
> I've posted a draft here: https://isocpp.org/files/papers/D2779R0.html
>
> Any feedback is welcome.
>


> If one uses std::string s(200); as a storage type instead of some other
contiguous container (like std::array<char, 200>), then the example above
would still have the problem of using the "wrong" size when s is converted
to a std::string_view. The conversion from std::string to std::string_view
remains however implicit.

Yes, but you can resize the "storage" std::string before converting it to a
string_view, so it does the right thing. You can't do that for the
std::array example.

> 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.

> In Qt, the author implemented
<https://isocpp.org/files/papers/D2779R0.html#biblio-qtpatch> 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 ;-)

Typo: vocabolary

I don't think Option 1 is a good idea, it still doesn't allow users to add
interoperability between two third-party libraries (because users should
not be specializing traits for types they don't own). And opt-in traits are
less convenient than something that just works.

I think Option 2 should be strongly considered as an alternative resolution
to LWG 3857. Has it been implemented in a std::string_view implementation?
I don't imagine any great difficulties, but it complicates the
implementation slightly and will be a little slower to compile. If users
*are* going to copy the API of string_view, including this constructor,
then this change would require even more work to replicate the API.