Am 04.11.25 um 19:03 schrieb Peter Dimov via Boost:
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 Doesn't this prove Marshalls point? `boost::core::string_view` is convertible to std::string and std::string_view so overloads of both will cause ambiguity.
This of course could be a "funny thing" to do but could reasonably occur if the string_view overload is e.g. conditional on C++17, or if having the null-termination allows a better code path. IMO if we can't have `boost::*::string_view` work as a drop-in for `std::string_view` without breaking things that weren't broken before we can't have those automatic conversions as much as I'd like to have them. If there aren't similar issues for *accepting* a boost-string_view then we could have at least the converting ctor so our interfaces can accept either type by specifying only boost-string_view. As a view-type is mainly an interface type anyway this might cover enough use cases already.