On Tue, 4 Nov 2025 at 12:05, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Andrey Semashev wrote:
Though, honestly, I didn't quite understand the objection back then. It seemed, Marshall was under the impression that relying on BOOST_NO_CXX17_HDR_STRING_VIEW was problematic for some reason.
Adding implicit conversions in this case had the potential to create a lot of subtle issues because code exists that does all sorts of funny things such as having conversion operators to char const*, or std::string, or boost::string_view, or std::string_view, or having overload sets taking all possible combinations of those.
So I understand his reluctance to commit to the potential maintenance burden created by that.
That is why we went the route we went; adding a second string_view with those conversions, not maintained by Marshall, so that the potential issues would not have to be addressed by him (but by me.)
Everything is not 100% fine,
https://github.com/boostorg/core/issues/167
but it mostly is, so I'd say we're at a point where we can make boost::string_view what core::string_view is.
Unrelated to boost::core::string_view, I think that boost::string_view itself should be compatible with std::string_view, and it seems to create unexpected behaviour for the user when this isn't the case. Although I do understand the argument that it would break code in certain places for overload sets, so maybe that ship has sailed already. If there's something we can do about this, I would be in favour of it. Like I said in my previous message in this thread, the lack of interoperability causes major issues for people (read: me) trying to use std::string_view in a code base that has previously only used boost::string_view. Basically my argument is, having a string_view that is in the top-level "boost" namespace is a very different creature than having it in a sub-namespace. Any average Joe programmer using Boost will reach for boost::string_view without knowing about any other string_views defined in other libraries. I think it's surprising and misleading if the "useful and correct" string_view implementation isn't the one in the top-level "boost" namespace.