Re: Opinions on introduction of string_view in Core

From: Peter Dimov (pdimov_at_[hidden])
Date: 2021-10-18 14:34:39

Marshall Clow wrote:
> The second one is about the long term use of boost::string_view.
> My opinion is that it is a transitional library, useful for people on older systems
> which do not have std::string_view.
> All things being equal, we (boost) should be encouraging people to transition
> away from boost::string_view to std::string_view when they can.

That's exactly the point though. People (library users) want to use
std::string_view, and libraries that don't want to require C++17 don't
have a good solution to offer them.

C++14 is still default on most distributions, so that's what Boost libraries
get compiled with.

Andrey's pontifications to the contrary notwithstanding, the best way to
address this use case is to make the library use a converting string_view in
its interface. This means that no additional overloads are required, and
the library can be compiled with C++14 and then be used with std::string_view.

Ideally, this "library API" type would be called boost::string_view. But if
this isn't possible, boost::core::string_view is second best. And if _that's_
impossible, third best is for this type to be called boost::library::string_view
(which was my original suggestion for Boost.JSON.)

Libraries already have this as a typedef, which can be toggled to refer to
boost::string_view or std::string_view, but this is not a satisfactory solution
for the reasons already outlined.

So yes, having two string views may be bad, but the alternative is having four
of five.

> On the other hand, boost::string_view has additional functionality w.r.t
> std::string_view, because of some odd (to me) choices by the standard
> committee (removing comparisons, for example).

Comparisons? I think std::string_view has comparisons?

There's also starts_with/ends_with, but that's in the C++20 std::string_view.
It also seems to have acquired `contains`, which I added.