On Tue, Nov 4, 2025 at 11:50 PM Ruben Perez via Boost <boost@lists.boost.org> wrote:
The whole situation is messy, made more so but the fact that boost::core::string_view does not live in a detail namespace and yet is in header boost/core/detail/string_view.hpp and lacks documentation. A simple Github search shows that it's being used in the wild (i.e. outside Boost).
Of course it'd be best if the authors involved agreed on a single, common string_view class across Boost. Barring that, my opinion is that boost::core::string_view should be properly lifted to public status and people will ultimately decide which one they use --this is unfortunately not the first case of such a situation, we already have it for iterator helpers provided both by Boost.Operator and Boost.Iterator.
I use core::string_view in Boost.MySQL, too, because implicit conversion to std::string_view is super important for me. core::string_view has std::format support, too. Not having any of these would have forced me to upgrade to C++17 already. So I'd like to see core::string_view as a public type, as it's already widely used in our interfaces.
Why don't we have a string_view in boost.compat? if we had a compat:;string_view that is identical to the C++17 implementation. We then have one standard with two implementations and not three slightly different string_views. Once compat adds this the consuming libraries (e.g. boost.mysql or boost.url) can use compat and the other implementations just become a relic that isn't used within boost anymore. The same would probably apply to core/span.