El 04/11/2025 a las 17:05, Klemens Morgenstern via Boost escribió:
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.
The main objection to the pull request was that a dependency was created. I'm sympathetic to that objection, I usually try to avoid explicit dependencies on Boost vs Std types and try to be interoperable with both. For instance, Boost.Interprocess timeouts can be used now with both Boost.Chrono and std::chrono types without including the corresponding headers, because you have the power of templates. I had the same problem with boost::container::basic_string. Should I construct it from boost or std string_views? If you are in a generic, templated class, many times you can support both: template<template <class, class> class BasicStringView> explicit basic_string(BasicStringView<CharT, Traits> sv, const allocator_type& a = allocator_type()) : base_t(allocator_traits_type::select_on_container_copy_construction(a)) { this->priv_terminate_string(); this->assign(sv); } where assign is: template<template <class, class> class BasicStringView> basic_string& operator=(BasicStringView<CharT, Traits> sv) { return this->assign(sv.data(), sv.size()); } Then a) the user has to include the proper include (not your problem) and b) your component is free of any dependency c) Other StringView types can be plugged if they offer I don't know if the proposed templated conversion operator would work flawlessly in all cases but I suggest we take this or similar templated approach so that utility/string_view does not depend on std::string_view, and we can then have a single string_view type in Boost. Just my 2 cents, Ion