Andrzej Krzemienski wrote:
Next, we read:
Aliases for standard types, such as string_view
https://master.url.cpp.al/url/ref/boost__urls__string_view.html, use their Boost equivalents.
After reading this, I expected that Boost.URL would use boost::string_view from Boost.Utility library: https://www.boost.org/doc/libs/1_79_0/libs/utility/doc/html/utility/utilitie... tring_view.html
But instead, it uses boost::core::string_view, which is an implementation detail from Boost.Core library: https://github.com/CPPAlliance/url/blob/master/include/boost/url/string_vie w.hpp
Again, this is news for me that Boost has two implementations of string_view. Why? Second, I do not think that Boost.URL should rely on the implementation details of Boost.Core. A better alternative would be to use the official boost::string_view from Boost.Utility. Or is there a good reason not to?
boost::core::string_view is convertible from/to std::string_view, which allows user code to pass std::string_view to a library's functions and store their return values into a std::string_view. This is a feature users request _very_ often nowadays since C++17 is common. We have proposed that these conversions be added to boost::string_view, but there were concerns that they won't work well in practice because of creating a mess of ambiguities. Which they kind of do, but it can be made to work. So boost::core::string_view is that boost::string_view, we have it because we can now try using it in library APIs and see if it's worth the bother. (So far it seems to be.) Where we go from here is undetermined yet. Maybe we integrate it into boost::string_view and retire the Core one, maybe we undelete the documentation of the Core one and make it official. I'd prefer to see it used in a released Boost library or two first, for a release or two. If it works, we decide what to do with it. There's been a discussion here about it: https://lists.boost.org/archives/boost/2021/10/252092.php