utility::string_view and core::detail::string_view
On Thu, Oct 23, 2025 at 4:17 AM Dmitry Arkhipov via Boost < boost@lists.boost.org> wrote:
Url's and Charconv's maintainers decided to not play along with the charade and reference boost::core::string_view directly with the obvious drawback that that type is not documented anywhere.
core::detail::string_view was added because this pull request FROM 2018 (seven years ago) was rejected: https://github.com/boostorg/utility/pull/51 We really need to fix this properly. In my opinion the maintainer of utility::string_view made the wrong choice when they rejected the pull request to make the constructors more useful. The consequence is that several Boost authors now use core::detail::string_view because it better satisfies user needs. At a time when people complain that Boost has its own version of std types, it would be best if we could come together and sort this. I would like to see the change which motivated core::detail::string view get applied to utility::string_view. Then we can change core::detail::string_view to be a deprecated alias, and after one release we can remove it. This solves everyone's problem: 1. Users get a type that works 2. Folks are not triggered by having two string views 3. Every library doesn't have to lift string_view into its own namespace 4. Cross-linking in documentation becomes possible With each new version of C++ we are asking more and more of Boost users. We are asking them to opt-in to our ecosystem which includes its own types similar yet sometimes incompatible with the standard types. It is our responsibility to make sure that we respect the user's trust, and deliver types which work for them. boost::utility::string_view breaks that trust at a time when we cannot afford to alienate. The consequence of the decision not to be flexible with the utility::string_view API is that now we have two string views. We have documentation issues. We have discovery issues. There is strife within the community. Yet more and more libraries are choosing core/detail/string_view.hpp instead of utility/string_view.hpp, simply because the core version works better. It is in the project's best interest to show the C++ community writ large that we can adapt and satisfy user needs. Lets do that by resolving the two string views. Thanks
On Thu, Oct 23, 2025, 11:41 PM Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Thu, Oct 23, 2025 at 4:17 AM Dmitry Arkhipov via Boost < boost@lists.boost.org> wrote:
Url's and Charconv's maintainers decided to not play along with the charade and reference boost::core::string_view directly with the obvious drawback that that type is not documented anywhere.
core::detail::string_view was added because this pull request FROM 2018 (seven years ago) was rejected: https://github.com/boostorg/utility/pull/51
We really need to fix this properly. In my opinion the maintainer of utility::string_view made the wrong choice when they rejected the pull request to make the constructors more useful.
[snip] I second this. Last year I was in the process of writing an issue to ask for this feature in boost::basic_string_view, when I discovered that it had already been discussed years earlier. From a user perspective, I work on a code base that was previously C++ <17, and is now C++ >=17. New code is written using std::string_view, but that doesn't negate the years of utilities and interfaces all throughout the code that use boost::string_view. At the end of the day, I just want to pass a std::string_view to an interface that expects a boost::string_view. I'm sure this is a common use case for people as their code moves to newer standards. I could either (1) convert my std::string_view to boost::string_view manually with data and size, (2) add a new overload to the utilities with proper constraints such that it's not ambiguous between the two overloads, or (3) replace the usage of boost::string_view with std::string_view outright. None of these are as simple as just passing a std::string_view to the interface, with no extra boilerplate or rejigging of the utility itself. C++17 is long since here, and std::string_view is a standard vocabulary type as much as std::string is. I think we're doing users a disservice by making them jump through hoops to convert between boost::string_view and std::string_view. This is a problem I've personally encountered, and I would be shocked if it isn't common. I'd love if we could reconsider, and give boost::string_view constructibility from (and convertibility to) std::string_view. Even better if that could be in time for 1.90. Thanks, Braden
El 24/10/2025 a las 6:39, Vinnie Falco via Boost escribió:
On Thu, Oct 23, 2025 at 4:17 AM Dmitry Arkhipov via Boost < boost@lists.boost.org> wrote:
Url's and Charconv's maintainers decided to not play along with the charade and reference boost::core::string_view directly with the obvious drawback that that type is not documented anywhere.
core::detail::string_view was added because this pull request FROM 2018 (seven years ago) was rejected: https://github.com/boostorg/utility/pull/51
We really need to fix this properly. In my opinion the maintainer of utility::string_view made the wrong choice when they rejected the pull request to make the constructors more useful. The consequence is that several Boost authors now use core::detail::string_view because it better satisfies user needs. At a time when people complain that Boost has its own version of std types, it would be best if we could come together and sort this.
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. Joaquín M López Muñoz
participants (3)
-
Braden Ganetsky -
Joaquin M López Muñoz -
Vinnie Falco