Why not just let boost::string_view be an alias to std::string_view when you compile in C++17 mode? /Peter On Tue, Nov 4, 2025 at 7:04 PM 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.
Since Core is not allowed to depend on Utility, one possible approach is to define boost::string_view in Core, make boost::core::string_view a using declaration, and include that in Utility.
Although if people insist on arbitrary Traits support, we probably need to do something else.
(Kind of unrelated, I see that I never got around to adding the string_view benchmarks to the Core repo. So much to do, so little time.)
_______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/FDNAEGE5...