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
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. Regards, Rubén.
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.
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.
This could be a good way to implement the "make it public" proposal. I already use Boost.Compat in MySQL, so I'd be happy to see string_view there. One thing to note is that boost::core::string_view does not support the Traits template parameter that boost::string_view and std::string_view do. I personally don't need this at all, but I don't know if that's true for the other libraries.
_______________________________________________ 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/YJQLWHLW...
On 11/4/2025 5:05 PM, Klemens Morgenstern via Boost wrote: [...]
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. Boost.Compat might be the ideal place for this (as it perfectly fits "Boost.Compat is a repository of C++11 implementations of standard components added in later C++ standards.").
But I suspect a string_view in Compat should necessarily have a Traits template argument? -- Gennaro Prota <https://prota.dev>
On Tue, Nov 4, 2025 at 8:26 AM Gennaro Prota via Boost < boost@lists.boost.org> wrote:
But I suspect a string_view in Compat should necessarily have a Traits template argument?
A good approach might be to start without the Traits and then only consider adding them when a demonstrable use-case arises. Thanks
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
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.
This is not viable for std::format is it?
El 04/11/2025 a las 17:31, Ruben Perez via Boost escribió:
This is not viable for std::format is it?
I haven't tried std::format yet, TBH. But std::format was not part of the mentioned pull request if I'm not wrong (core::string_view supports it, apparently): https://github.com/boostorg/utility/pull/51/commits/40614288c8616f430e59d7f5... Not an expert on std::format to know how we could achieve the same without a hard dependency (if possible). Best, Ion
Three points: a) Having different string_view types defined in two (or potentially more given the compat suggestion) Boost libraries strikes me as extremely confusing for the users (previous emails have shown it to be confusing for Boost contributors, so it must be even more so for naive users of Boost). It makes sesnse to pick one single design and (ideally though I understand backwards compatibility may be a concern) a single location. b) I personally think that allowing a string_view type to be constructible from std::string_view is eminently sensible and aids usability and interoperability between Boost and non-Boost libraries. People don't like introducing a dependency on std::string_view. That is easily solved by a templated constructor. Note that std::basic_string uses a similar trick (see constructor 9 on https://en.cppreference.com/w/cpp/string/basic_string/basic_string.html), and the StringViewLike type can be constrained in whatever way you are comfortable. (personally I don't have any objection to simply checking '__has_include(<string_view>)' and using it directly but I'm pointing out that if people don't like that there are alternatives) c) People seem to be mixing this up with <format> support. Such a constructor does not impact support for std::format or <fmt> - its presence or absence is entirely orthogonal to whether *::string_view provides std::format support. In fact adding support for std::format to a non-std string_view type is relatively straightforward (if need be I can do a simple demo in godbolt) - you know std::string_view must be available in C++20 (required for std::format) and can therefore create a formatter type that delegates to the formatter for std::string_view. On 04/11/2025 16:54, Ion Gaztañaga via Boost wrote:
El 04/11/2025 a las 17:31, Ruben Perez via Boost escribió:
This is not viable for std::format is it?
I haven't tried std::format yet, TBH. But std::format was not part of the mentioned pull request if I'm not wrong (core::string_view supports it, apparently):
https://github.com/boostorg/utility/pull/51/commits/40614288c8616f430e59d7f5...
Not an expert on std::format to know how we could achieve the same without a hard dependency (if possible).
Best,
Ion _______________________________________________ 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/IZR5BY7P...
Ion Gaztañaga wrote:
Not an expert on std::format to know how we could achieve the same without a hard dependency (if possible).
It's going to be possible after P3070 https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2023/p3070r0.html by defining a function `format_as`, but that's C++29. By then, I sincerely hope that we would have mostly moved to C++17 and the point will have been made moot.
On 4 Nov 2025 19:26, Ion Gaztañaga via Boost wrote:
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.
boost/utility/string_view.hpp already includes <string>, which is a more expensive dependency than <string_view>. Replacing the former with the latter, when possible, would likely improve compile times. 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.
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.)
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...
Peter Koch Larsen wrote:
Why not just let boost::string_view be an alias to std::string_view when you compile in C++17 mode?
Because then the compiled library and the user code need to either both be built in C++17 mode, or both be built in not-C++17 mode, and this creates problems if you're using a prebuilt Boost, e.g. one from apt-get.
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.
On Tue, 4 Nov 2025 at 12:05, 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.
Unrelated to boost::core::string_view, I think that boost::string_view itself should be compatible with std::string_view, and it seems to create unexpected behaviour for the user when this isn't the case. Although I do understand the argument that it would break code in certain places for overload sets, so maybe that ship has sailed already. If there's something we can do about this, I would be in favour of it. Like I said in my previous message in this thread, the lack of interoperability causes major issues for people (read: me) trying to use std::string_view in a code base that has previously only used boost::string_view. Basically my argument is, having a string_view that is in the top-level "boost" namespace is a very different creature than having it in a sub-namespace. Any average Joe programmer using Boost will reach for boost::string_view without knowing about any other string_views defined in other libraries. I think it's surprising and misleading if the "useful and correct" string_view implementation isn't the one in the top-level "boost" namespace.
On Sun, Nov 16, 2025 at 6:48 PM Braden Ganetsky via Boost < boost@lists.boost.org> wrote:
...
Now that the release is over with I'd like to get back to this conversation. I believe there is enough smoke / friction here that warrants a resolution. I would like to see: * Only one string_view in Boost * In a public directory (not detail) * Strong interop with std::string_view Boost already has enough detractors that we can't afford to push an unergonomic duplicate of a std library component (especially one that is already 8 years old). If the project is going to justify its level of std type duplication then we need to provide added value. The string_view from utility is not ergonomic, while the one in core::detail is. Thanks
On 12/11/25 20:44, Vinnie Falco via Boost wrote: > On Sun, Nov 16, 2025 at 6:48 PM Braden Ganetsky via Boost < > boost@lists.boost.org> wrote: > >> ... > > > Now that the release is over with I'd like to get back to this > conversation. I believe there is enough smoke / friction here that warrants > a resolution. I would like to see: > > * Only one string_view in Boost > * In a public directory (not detail) > * Strong interop with std::string_view As I understand it, this is a political problem. - boost::string_view has already been accepted into Boost. - Community consensus is overwhelmingly that it should interop better with std::string_view, but its maintainer doesn't want to make that change. - There is no process for forcing the maintainer to make that change. - There is no process for forcibly replacing the maintainer. - There is no process for removing the library from Boost and replacing it with another string_view library. Once a library passes its review and is accepted, it remains a part of Boost forever while still being under the control of its original author. If a problem comes up after review, the option is to politely the library's maintainer to please fix the problem. -- Rainer Deyke - rainerd@eldwood.com
Rainer Deyke wrote: > On 12/11/25 20:44, Vinnie Falco via Boost wrote: > > On Sun, Nov 16, 2025 at 6:48 PM Braden Ganetsky via Boost < > > boost@lists.boost.org> wrote: > > > >> ... > > > > > > Now that the release is over with I'd like to get back to this > > conversation. I believe there is enough smoke / friction here that > > warrants a resolution. I would like to see: > > > > * Only one string_view in Boost > > * In a public directory (not detail) > > * Strong interop with std::string_view > As I understand it, this is a political problem. > - boost::string_view has already been accepted into Boost. > - Community consensus is overwhelmingly that it should interop better with > std::string_view, but its maintainer doesn't want to make that change. > - There is no process for forcing the maintainer to make that change. > - There is no process for forcibly replacing the maintainer. > - There is no process for removing the library from Boost and replacing it > with another string_view library. Placing the blame solely there is not entirely fair. There's a reasonably straightforward process to follow and it's 1. make boost::core::string_view public 2. make boost::string_view an alias for it but when we try to do (1) there're always complaints that "users will be confused by these two different string_view classes"... as if users aren't already confused enough by (a) already having two different string_view classes _and_ (b) one of them being undocumented.
On 12 Dec 2025 23:23, Peter Dimov via Boost wrote: > Rainer Deyke wrote: >> On 12/11/25 20:44, Vinnie Falco via Boost wrote: >>> On Sun, Nov 16, 2025 at 6:48 PM Braden Ganetsky via Boost < >>> boost@lists.boost.org> wrote: >>> >>>> ... >>> >>> >>> Now that the release is over with I'd like to get back to this >>> conversation. I believe there is enough smoke / friction here that >>> warrants a resolution. I would like to see: >>> >>> * Only one string_view in Boost >>> * In a public directory (not detail) >>> * Strong interop with std::string_view >> As I understand it, this is a political problem. >> - boost::string_view has already been accepted into Boost. >> - Community consensus is overwhelmingly that it should interop better with >> std::string_view, but its maintainer doesn't want to make that change. >> - There is no process for forcing the maintainer to make that change. >> - There is no process for forcibly replacing the maintainer. >> - There is no process for removing the library from Boost and replacing it >> with another string_view library. > > Placing the blame solely there is not entirely fair. > > There's a reasonably straightforward process to follow and it's > > 1. make boost::core::string_view public > 2. make boost::string_view an alias for it This could work if boost::core::string_view and boost::string_view were compatible, but they are not. > but when we try to do (1) there're always complaints that "users will be > confused by these two different string_view classes"... as if users aren't > already confused enough by (a) already having two different string_view > classes _and_ (b) one of them being undocumented. For users, boost::core::string_view should not exist. At least, that's how I understand it should be.
On 13 Dec 2025 03:13, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
For users, boost::core::string_view should not exist. At least, that's how I understand it should be.
I have no idea what this is supposed to mean.
AFAIR, boost::core::string_view was supposed to be used as function arguments or return types so that users can pass or receive the returned values into std::string_view or boost::string_view, whichever they use in their code bases. I.e. users were not supposed to use boost::core::string_view directly, it's an implementation detail of Boost, so for them it shouldn't exist.
Andrey Semashev wrote:
On 13 Dec 2025 03:13, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
For users, boost::core::string_view should not exist. At least, that's how I understand it should be.
I have no idea what this is supposed to mean.
AFAIR, boost::core::string_view was supposed to be used as function arguments or return types so that users can pass or receive the returned values into std::string_view or boost::string_view, whichever they use in their code bases. I.e. users were not supposed to use boost::core::string_view directly, it's an implementation detail of Boost, so for them it shouldn't exist.
It's not possible for a part of the public interface to be "an implementation detail".
On 12/12/25 22:30, Andrey Semashev via Boost wrote:
For users, boost::core::string_view should not exist. At least, that's how I understand it should be.
In practice, I now have three overloads for some of my functions: std::string_view, boost::string_view, and boost::core::string_view. I need std::string_view in order to interoperate with the standard library. I need boost::string_view to interoperate with Boost. I need boost::core::string_view to resolve the ambiguity caused by having both of the others. From my perspective, the ideal situation would be to have *no* string_view in Boost and just use std::string_view throughout. Unfortunately that's completely impracticable, for various reasons. -- Rainer Deyke - rainerd@eldwood.com
Rainer Deyke wrote:
In practice, I now have three overloads for some of my functions: std::string_view, boost::string_view, and boost::core::string_view. I need std::string_view in order to interoperate with the standard library. I need boost::string_view to interoperate with Boost.
Almost nothing in Boost uses boost::string_view, so you don't need it in order to interoperate with Boost. Maybe you need it in order to interoperate with other code bases that use boost::string_view, but not with Boost. To interoperate with the stdlib, having a boost::core::string_view overload should be enough; that's what it was designed to do.
On 12/13/25 10:35, Peter Dimov via Boost wrote:
Rainer Deyke wrote:
In practice, I now have three overloads for some of my functions: std::string_view, boost::string_view, and boost::core::string_view. I need std::string_view in order to interoperate with the standard library. I need boost::string_view to interoperate with Boost.
Almost nothing in Boost uses boost::string_view, so you don't need it in order to interoperate with Boost.
This does seem to be the case now. My code still works if I remove the boost::string_view overloads. It wasn't the case at the time when I wrote the overloads.
To interoperate with the stdlib, having a boost::core::string_view overload should be enough; that's what it was designed to do. This, on the other hand, does not seem to be the case. I get compile errors if I remove either the std::string_view or the boost::core::string_view overloads.
-- Rainer Deyke - rainerd@eldwood.com
On Sat, Dec 13, 2025 at 7:06 AM Rainer Deyke via Boost < boost@lists.boost.org> wrote:
This, on the other hand, does not seem to be the case. I get compile errors if I remove either the std::string_view or the boost::core::string_view overloads.
Could you please create a small reproducing example on https://godbolt.org ? Thanks
On 12/13/25 16:46, Vinnie Falco via Boost wrote:
On Sat, Dec 13, 2025 at 7:06 AM Rainer Deyke via Boost < boost@lists.boost.org> wrote:
This, on the other hand, does not seem to be the case. I get compile errors if I remove either the std::string_view or the boost::core::string_view overloads.
Could you please create a small reproducing example on https://godbolt.org ?
https://godbolt.org/z/n7esssG6E -- Rainer Deyke - rainerd@eldwood.com
Rainer Deyke wrote:
On 12/13/25 16:46, Vinnie Falco via Boost wrote:
On Sat, Dec 13, 2025 at 7:06 AM Rainer Deyke via Boost < boost@lists.boost.org> wrote:
This, on the other hand, does not seem to be the case. I get compile errors if I remove either the std::string_view or the boost::core::string_view overloads.
Could you please create a small reproducing example on https://godbolt.org ?
Thanks. Unfortunately there's nothing we can do to enable this on the core::string_view side. It's fixable by changing the my_class constructor to a template like this: https://godbolt.org/z/bK84j3q39 which incidentally gives you support for `char const*` and `std::string` for free (and for boost::string_view should anyone still need it.) To avoid mentioning core::string_view in your own code, you can do the same except with std::string_view: https://godbolt.org/z/YGT3sYssW This no longer supports boost::string_view, but that's acceptable. Ultimately though, the only thing that will "fix" all these issues once and for all is moving to a C++17 baseline in the Boost libraries that suffer from them, and migrating to std::string_view. The time might be coming. C++17 is the default on GCC 11 and later, and Ubuntu 22.04 has GCC 11 as the system compiler. We just need 20.04 to die (it's already EOL I think?) and figure out the situation on macOS. We'll lose msvc-14.0 though.
On 11 Dec 2025 22:44, Vinnie Falco via Boost wrote:
On Sun, Nov 16, 2025 at 6:48 PM Braden Ganetsky via Boost < boost@lists.boost.org> wrote:
...
Now that the release is over with I'd like to get back to this conversation. I believe there is enough smoke / friction here that warrants a resolution. I would like to see:
* Only one string_view in Boost * In a public directory (not detail) * Strong interop with std::string_view
Boost already has enough detractors that we can't afford to push an unergonomic duplicate of a std library component (especially one that is already 8 years old). If the project is going to justify its level of std type duplication then we need to provide added value. The string_view from utility is not ergonomic, while the one in core::detail is.
I think, this discussion will end with nothing, as we had it before. If we want to change the status quo, we need to come to a community decision on what to do. The process we have for this is a review. Specifically, we need a proposal of what to do about boost::string_view and boost::core::string_view, which we need to review and accept or reject it in the end.
Andrey Semashev wrote:
I think, this discussion will end with nothing, as we had it before. If we want to change the status quo, we need to come to a community decision on what to do. The process we have for this is a review.
I don't see what's there to review. core::string_view is more than eligible for being a documented component. It's being used by 8 Boost libraries in their user-facing API. This is exactly what Core was created for. Even if we applied an unreasonably high standard for what needs to go into Core - and we don't - it still clears it. I can see no technical or procedural justification for objecting to core::string_view. At this point, I'm inclined to start to think that objections are malicious in nature. Amusingly, the "official" boost::string_view is only used twice, and one of these is probably a mistake that should be rectified. :-)
On 13 Dec 2025 21:23, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
I think, this discussion will end with nothing, as we had it before. If we want to change the status quo, we need to come to a community decision on what to do. The process we have for this is a review.
I don't see what's there to review.
core::string_view is more than eligible for being a documented component. It's being used by 8 Boost libraries in their user-facing API. This is exactly what Core was created for.
Even if we applied an unreasonably high standard for what needs to go into Core - and we don't - it still clears it.
I can see no technical or procedural justification for objecting to core::string_view.
You know very well that the issue is not the technical qualities of core::string_view.
At this point, I'm inclined to start to think that objections are malicious in nature.
It sounds like you're accusing someone (me in particular, perhaps?) of sabotaging your work due to difference in opinion. Is this the case? If so, why don't you just go ahead and do whatever you think is right? What's the point in discussing things anyway, when there are only two opinions, yours and wrong? Honestly, at this point I'm this close to just giving up on this topic, and probably Boost.Core as well. But maybe that's exactly what people want.
Amusingly, the "official" boost::string_view is only used twice, and one of these is probably a mistake that should be rectified. :-)
If the community overwhelmingly prefers core::string_view over boost::string_view, a review of a proposal to replace the latter with the former would surely show that. That's the point of the review - to gain community-wide consensus and then act on it. A review is also a way to overcome a difference in opinion, as the review manager has the power to choose whatever he thinks is right, even if that decision is not universally popular. Anyway, I'm done with this argument. I've said enough already and I've tried to suggest arbitration in the form of a review. You can do whatever.
Andrey Semashev wrote:
What's the point in discussing things anyway, when there are only two opinions, yours and wrong?
It's not quite clear to me what your opinion is. What's the right thing to do? Nothing at all? You find the status quo satisfactory and see no problem with it?
On 14 Dec 2025 03:17, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
What's the point in discussing things anyway, when there are only two opinions, yours and wrong?
It's not quite clear to me what your opinion is. What's the right thing to do? Nothing at all? You find the status quo satisfactory and see no problem with it?
Having multiple string_views in Boost is a problem. Having multiple string_views that are publicly documented and advertised to users is a bigger problem. So no, I find neither the status quo nor what you propose satisfactory. I was initially against introduction core::string_view because I thought this would happen, and it did. Libraries now just have to support one more string_view in their interfaces. My hope was that at least the libraries would mention a concept of string_view in their documentation instead of exposing the mess we have internally, so that users would only deal with std::string_view or boost::string_view, whichever they choose for themselves. But apparently that didn't happen either, and some libraries documented or referenced core::string_view. I already said what I think should be done. Make a proposal to keep just one string_view in Boost. Whether that is core::string_view or boost::string_view, I don't really care at this point. Then the community reviews that proposal. Then, if it's accepted, we act on it. Meaning, one of the implementations will have to go eventually. PS: Oh, right, I forgot we also have boost::string_ref. That one definitely needs to go.
On Sun, Dec 14, 2025 at 12:39 PM Andrey Semashev via Boost <boost@lists.boost.org> wrote:
I already said what I think should be done. Make a proposal to keep just one string_view in Boost. Whether that is core::string_view or boost::string_view.
Considering that most codebases use C++17 or newer, and that boost::string_view is neither constructible from nor convertible to std::string_view, using it in a public API of a library is effectively as good as using: namespace mylib { struct string_view { const char *ptr; std::size_t len; }; } // namespace mylib I suspect very few users actually use this type, if any. We can likely leverage that. We could promote core::string_view to the boost namespace and use boost/string_view.hpp as the include path. I would be happy to write a proposal if no one is going to volunteer. Thanks
Andrey Semashev wrote:
I was initially against introduction core::string_view because I thought this would happen, and it did. Libraries now just have to support one more string_view in their interfaces. My hope was that at least the libraries would mention a concept of string_view in their documentation instead of exposing the mess we have internally, so that users would only deal with std::string_view or boost::string_view, whichever they choose for themselves. But apparently that didn't happen either, and some libraries documented or referenced core::string_view.
It didn't happen because it's impossible. You can't return a concept from a function, you have to return a specific type. Neither can this type be chosen by the user, especially for compiled libraries. We've been over all of this before; this is precisely why core::string_view exists, to be that type returned from library functions while still allowing the user the choice of assigning the result to whatever string_view type he prefers.
I already said what I think should be done. Make a proposal to keep just one string_view in Boost. Whether that is core::string_view or boost::string_view, I don't really care at this point. Then the community reviews that proposal. Then, if it's accepted, we act on it.
I'm not going to be the one writing this proposal, because, contrary to your insinuations, I don't actually have an opinion on how we need to proceed with it (there are options, some of which harder than others), and neither do I see any particular problem with having two string_view classes in Boost. Since this problem will eventually go away on its own, I'm not particularly invested in solving it now. What I do have an opinion about is that core::string_view should be public and documented, because this solves an immediate problem for the library authors who currently use it in their public APIs (and for the users who encounter it). I'm perfectly willing to leave the rest to the maintainers of Utility, where boost::string_view resides.
On Sun, Dec 14, 2025 at 5:35 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Since this problem will eventually go away on its own, I'm not particularly invested in solving it now.
What I do have an opinion about is that core::string_view should be public and documented, because this solves an immediate problem for the library authors who currently use it in their public APIs (and for the users who encounter it).
There are modern libraries like Boost.Json and Boost.URL (and the upcoming Boost.Beast2) that use core::string_view in their public interfaces and will likely continue to support C++11 for a long time. I think making core::string_view public is the least we can do. It does not make sense to reference a type in the docs that is included from boost/core/detail/string_view.hpp.
This amazing discussion reminded me that I had some string_view benchmarks sitting on my drive since forever, and I remembered that there was even an issue about it which I never addressed: https://github.com/boostorg/core/issues/114 So I added them now, four years too late. https://github.com/boostorg/core/commit/b7fdbf41a7523e872960b56108c26db1cb1d... In addition to adding them I also ran them, and I observed something that might be of interest: Microsoft's std::string_view hasn't stood still and, in VS2022, has AVX2 optimized implementations of (at least) find_first_of, which makes it twice as fast as core::string_view.
On Sun, Dec 14, 2025 at 12:11 PM Peter Dimov via Boost < boost@lists.boost.org> wrote:
In addition to adding them I also ran them, and I observed something that might be of interest: Microsoft's std::string_view hasn't stood still and, in VS2022, has AVX2 optimized implementations of (at least) find_first_of, which makes it twice as fast as core::string_view.
We're gonna need that tech here: https://github.com/boostorg/url/blob/cbaf493668b7bfbb4da0a5857326cc0b3353bd9... Thanks
On 4 Nov 2025 19:05, Klemens Morgenstern via Boost wrote:
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.
If my counting is right, we'd have three, plus std::string_view. As if two weren't enough. BTW, the version in Boost.Compat wouldn't have a conversion operator to/from std::string_view because one doesn't exist in std::string_view and Boost.Compat implements standard components verbatim.
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.
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.
For the record, the problem with not having explicit std::format support is specially hostile for users because the problem manifests at runtime rather than compile-time. Since XXX::string_view is a range, it will be formatted as a range of characters instead of a string. You can see what it looks like here: https://godbolt.org/z/W7acqxYWd Copying a snippet here just in case: std::println("{}", std::string_view("hello world")); std::println("{}", boost::core::string_view("hello world")); std::println("{}", boost::string_view("hello world")); Prints: hello world hello world ['h', 'e', 'l', 'l', 'o', ' ', 'w', 'o', 'r', 'l', 'd']
In case anyone is curious how to implement support for <format> in boost::string_view by delegating to the formatter for std::string_view: https://godbolt.org/z/YsWKrEz3P On 04/11/2025 16:41, Ruben Perez via Boost wrote:
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. For the record, the problem with not having explicit std::format support is specially hostile for users because the problem manifests at runtime rather than compile-time. Since XXX::string_view is a range, it will be formatted as a range of characters instead of a string. You can see what it looks like here: https://godbolt.org/z/W7acqxYWd
Copying a snippet here just in case:
std::println("{}", std::string_view("hello world")); std::println("{}", boost::core::string_view("hello world")); std::println("{}", boost::string_view("hello world"));
Prints:
hello world hello world ['h', 'e', 'l', 'l', 'o', ' ', 'w', 'o', 'r', 'l', 'd'] _______________________________________________ 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/LGBW4G4F...
Mungo Gill wrote:
In case anyone is curious how to implement support for <format> in boost::string_view by delegating to the formatter for std::string_view: https://godbolt.org/z/YsWKrEz3P
There's no way to portably forward-declare things in std (even if we discount the fact that this is explicitly called out as undefined behavior.) https://godbolt.org/z/9f5xMEPd1
On 4 Nov 2025 22:19, Peter Dimov via Boost wrote:
Mungo Gill wrote:
In case anyone is curious how to implement support for <format> in boost::string_view by delegating to the formatter for std::string_view: https://godbolt.org/z/YsWKrEz3P
There's no way to portably forward-declare things in std (even if we discount the fact that this is explicitly called out as undefined behavior.)
Although this is true, we also have utilities for doing this in all widespread implementations, and some Boost libraries already forward-declare std components: https://godbolt.org/z/GrEY377qb I wish this utility was made more public.
El 04/11/2025 a las 21:08, Andrey Semashev via Boost escribió:
On 4 Nov 2025 22:19, Peter Dimov via Boost wrote:
Mungo Gill wrote:
In case anyone is curious how to implement support for <format> in boost::string_view by delegating to the formatter for std::string_view: https://godbolt.org/z/YsWKrEz3P
There's no way to portably forward-declare things in std (even if we discount the fact that this is explicitly called out as undefined behavior.)
Although this is true, we also have utilities for doing this in all widespread implementations, and some Boost libraries already forward-declare std components:
https://godbolt.org/z/GrEY377qb
I wish this utility was made more public.
I just replied with the same content, we are somehow synchronized. We could also have a VERY lightweight library, properly tested, something like: https://github.com/olegpublicprofile/stdfwd Best, Ion
El 04/11/2025 a las 20:19, Peter Dimov via Boost escribió:
Mungo Gill wrote:
In case anyone is curious how to implement support for <format> in boost::string_view by delegating to the formatter for std::string_view: https://godbolt.org/z/YsWKrEz3P
There's no way to portably forward-declare things in std (even if we discount the fact that this is explicitly called out as undefined behavior.)
No standard way, but there is a practial way using some tricks https://github.com/boostorg/move/blob/develop/include/boost/move/detail/std_... https://github.com/boostorg/container/blob/develop/include/boost/container/d... See your example using Boost.Move internal headers: https://godbolt.org/z/Eez6f9cf5 In spite of the "official UB" I think we should have a StdFwd library in Boost (or maybe some header doing the ugly stuff in Boost.Config). Best, Ion
El 04/11/2025 a las 20:07, Mungo Gill via Boost escribió:
In case anyone is curious how to implement support for <format> in boost::string_view by delegating to the formatter for std::string_view: https://godbolt.org/z/YsWKrEz3P
I really don't like when the standard requires specializing std types to plug user-defined types in the system. That makes your type dependent on types and includes users might not need at all. Having to specialize std::formatter is an arbitraty decision that increases coupling. The alternative could be to have typedef of name "std_formatter_t" that could do the same work. I prefer the approach of defining some member functions, operations or typedefs that the standard library must find in your type, e.g.: having "operator < in your type" instead of a specializing std::less. Define "hash_value" instead of specializing "std::hash". Best, Ion
On Tue, Nov 4, 2025 at 1:50 PM Ion Gaztañaga via Boost < boost@lists.boost.org> wrote:
I prefer the approach...
I like the tag_invoke model pioneered by Eric Niebler, et. al. who used to be active in Boost (where did he go?) Ironically with 3-year rapid "innovation" of C++ Standard versions the tag_invoke mechanism has fallen out of favor. See: https://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1895r0.pdf Thanks
El 04/11/2025 a las 23:23, Vinnie Falco escribió:
On Tue, Nov 4, 2025 at 1:50 PM Ion Gaztañaga via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
I prefer the approach...
I like the tag_invoke model pioneered by Eric Niebler, et. al. who used to be active in Boost (where did he go?) Ironically with 3-year rapid "innovation" of C++ Standard versions the tag_invoke mechanism has fallen out of favor.
See: https://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1895r0.pdf <https://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1895r0.pdf>
Interesting, but a bit convoluted for my taste ;-) Best, Ion
On Tue, Nov 4, 2025 at 2:59 PM Ion Gaztañaga <igaztanaga@gmail.com> wrote:
https://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1895r0.pdf <https://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1895r0.pdf>
Interesting, but a bit convoluted for my taste ;-)
Apologies, I should clarify. The paper goes on about Customization Point Objects ("CPOs") and what not, which is a lot of additional complexity. Some of that is justified as it relates to what is needed for a standard library implementation. We don't need all that, so just the plain `tag_invoke` is good enough. Boost.JSON uses this mechanism. The guidance becomes "overload tag_invoke for the desired tag and your type." So for example Boost.JSON declares the "value_to" tag, and in order to convert a json::value to your type T, you would write this function in the same namespace as T: void tag_invoke( boost::json::value_to_tag, T&, boost::json::value const& ); I like this better than specializing a class template for a few reasons. Thanks
On Wed, Nov 5, 2025, at 12:13 AM, Vinnie Falco via Boost wrote:
On Tue, Nov 4, 2025 at 2:59 PM Ion Gaztañaga <igaztanaga@gmail.com> wrote:
Interesting, but a bit convoluted for my taste ;-)
[...] in order to convert a json::value to your type T, you would write this function in the same namespace as T:
void tag_invoke( boost::json::value_to_tag, T&, boost::json::value const& );
I like this better than specializing a class template for a few reasons.
+1 I like the libraries that use this approach. It's the best way I know to truly decouple the provider and consumer of this extension mechanism. Seth
El 05/11/2025 a las 0:13, Vinnie Falco escribió:
On Tue, Nov 4, 2025 at 2:59 PM Ion Gaztañaga <igaztanaga@gmail.com <mailto:igaztanaga@gmail.com>> wrote:
> https://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1895r0.pdf <https://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1895r0.pdf> > <https://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1895r0.pdf <https://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1895r0.pdf>>
Interesting, but a bit convoluted for my taste ;-)
Apologies, I should clarify. The paper goes on about Customization Point Objects ("CPOs") and what not, which is a lot of additional complexity. Some of that is justified as it relates to what is needed for a standard library implementation. We don't need all that, so just the plain `tag_invoke` is good enough. Boost.JSON uses this mechanism. The guidance becomes "overload tag_invoke for the desired tag and your type." So for example Boost.JSON declares the "value_to" tag, and in order to convert a json::value to your type T, you would write this function in the same namespace as T:
void tag_invoke( boost::json::value_to_tag, T&, boost::json::value const& );
I like this better than specializing a class template for a few reasons.
Thanks for the explanation, this seems a useful extension of the plain ADL customization, avoiding name clashes between customization points. Best, Ion
participants (15)
-
Alexander Grund -
Andrey Semashev -
Braden Ganetsky -
Gennaro Prota -
Ion Gaztañaga -
Joaquin M López Muñoz -
Klemens Morgenstern -
Mohammad Nejati -
Mungo Gill -
Peter Dimov -
Peter Koch Larsen -
Rainer Deyke -
Ruben Perez -
Seth -
Vinnie Falco