g.peterhoff--- wrote:
Have you come to a conclusion how this should be handled (in the future)?
The problem is basically that there are different implementations for string_view. I don't know why it was done this way.
The motivation for creating boost::core::string_view was that there exist several pre-C++17 Boost libraries that want to take and return string views as parameters and return values. This is a problem because C++17 users prefer to use std::string_view. These libraries used to offer a configuration macro that switched between boost::string_view and std::string_view (e.g. BOOST_LIBNAME_USE_STD_STRING_VIEW.) But this is also a problem because, since these libraries are compiled, users of precompiled libraries get one or the other. Their defining the macro cannot affect how the library has been built. That is why I created boost::core::string_view, which is a string view type that is also convertible from and to std::string_view. So the library API can be boost::core::string_view api_function( boost::core::string_view key ); but C++17 users can both pass std::string_view to it and store the return value into std::string_view. There have been attempts to add these conversions to boost::string_view, but those have been rejected by the maintainer. When I tried to add boost::core::string_view to Core as a documented and public component, people here objected. So it's not documented and public now. Hope those people are happy for heroically preventing components from being documented. So we are where we are.