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.