Re: Opinions on introduction of string_view in Core

From: Peter Dimov (pdimov_at_[hidden])
Date: 2021-10-20 03:18:08

Gavin Lambert wrote:

> What I'm not clear on is the intended future of Boost.Utility's string_view.

The future of Utility's string_view will be what we decide it to be. As already
stated, in order to build a strong case for the boost::string_view type to be
convertible and interoperable, we need to actually demonstrate that this
interoperable type is necessary, desirable, and can actually be made to work.

While it's possible, if not easy, to achieve the first two via discussions on the
list, the third one requires actual practical use, because we need to root out
all the ambiguities and show that the potential problems they create can be
solved adequately.

Once we have consensus that we want the interoperable type to be called
boost::string_view, we can decide how to do it, whether by adding
conversions to Utility's string_view, or by promoting Core's one and removing
the one in Utility.

The alternative option of leaving boost::string_view as is doesn't particularly
appeal to me. I think that it should (at least broadly) track the C++23 changes
to std::string_view, and that includes a converting constructor. So if we assume
a C++23 std::string_view and a C++23-compatible boost::string_view, each
will convert to the other using this constructor. I see no reason to make
users of C++17's std::string_view wait for C++23 in order to be able to take
advantage of this interoperability between the two string views, which is why
I think we should add a conversion to std::string_view now, rather than
waiting for std::string_view to add a conversion from, in 2023.

But even if the ultimate fate of boost::string_view is to remain as is, this doesn't
change anything today. In all three cases it starts with adding the converting
string_view _somewhere_ and then using it in Boost library interfaces.