Andrey Semashev wrote:
The main motivation for introducing the new implementation is adding conversions to/from std::string_view, which were proposed to Boost.Utility and rejected a while ago:
The scenario being addressed here is that of a Boost library that does not require C++17, yet its users want to use std::string_view when interacting with the library. That is, the library API is string_view api_function( string_view str ); and some of the end users aren't on C++17 and will use the library-provided string_view, and others are on C++17 and want to use std::string_view, both to pass it as an argument to `api_function`, and to store its result. Currently, if the library uses boost::string_view, it can't receive std::string_view arguments. This is fixable by adding an additional overload that takes a `std::string_view`, but other use cases now become ambiguous, and need to be addressed separately either by yet more additional overloads, or by templating some of the overloads, which is fragile. And, this doesn't solve the problem of the return value. No matter what is returned, some of the users will not be able to store the return value in their preferred string_view. A string_view type that converts from and to std::string_view solves this problem, as the API above now works for both passing, and storing the result into, `std::string_view`. boost::core::string_view is this type. The alternative is for every library that has the above problem to supply its own string_view, which will be a copy of boost::core::string_view. This is exactly why Core was created - to factor out duplicate functionality. (Before you suggest that the library should use boost::string_view under C++14 and std::string_view under C++17, note that this makes it impossible to build the library under C++14 and use it from C++17, which is a common scenario when using the system-provided Boost package.)