Gavin Lambert wrote:
What I'm not clear on is the intended future of Boost.Utility's string_view.
The future of Utility's string_view will be what we decide it to be. As already stated, in order to build a strong case for the boost::string_view type to be convertible and interoperable, we need to actually demonstrate that this interoperable type is necessary, desirable, and can actually be made to work. While it's possible, if not easy, to achieve the first two via discussions on the list, the third one requires actual practical use, because we need to root out all the ambiguities and show that the potential problems they create can be solved adequately. Once we have consensus that we want the interoperable type to be called boost::string_view, we can decide how to do it, whether by adding conversions to Utility's string_view, or by promoting Core's one and removing the one in Utility. The alternative option of leaving boost::string_view as is doesn't particularly appeal to me. I think that it should (at least broadly) track the C++23 changes to std::string_view, and that includes a converting constructor. So if we assume a C++23 std::string_view and a C++23-compatible boost::string_view, each will convert to the other using this constructor. I see no reason to make users of C++17's std::string_view wait for C++23 in order to be able to take advantage of this interoperability between the two string views, which is why I think we should add a conversion to std::string_view now, rather than waiting for std::string_view to add a conversion from, in 2023. But even if the ultimate fate of boost::string_view is to remain as is, this doesn't change anything today. In all three cases it starts with adding the converting string_view _somewhere_ and then using it in Boost library interfaces.