Gavin Lambert wrote:
The best choice seems to be to add the necessary conversions to the existing boost::string_view, rather than adding a new one. It just seems like you're trying to do an end-run around this because you're having trouble convincing the maintainer that it's a good idea.
Yes and no, but mostly no. We're having trouble convincing the maintainer on two levels. The first one - I'll use the terms Marshall himself used - is the philosophical one, the need for the feature. We've apparently been unable to communicate this need and everyone so far has been hard at work trying to explain to us that this need doesn't exist. So one way to communicate this is to actually start using a converting string_view in the libraries that need it, say Boost.JSON, and then point to it. The second level is technical. Implicit conversions are a pain. They create ambiguities in places where one doesn't expect. The way to convince Marshall that the conversions are worth it and will create more value than they will cost is... ... yes, to actually start using a converting string_view in one library, say Boost.JSON, gather experience and then point to it as proof that the conversions "work". This could in principle have been accomplished by adding a private string_view to JSON, rather than one to Core. But the maintainers of Boost.JSON were unwilling to commit to that because it's a lot of work and the component is foundational and usable in more than one library, so it needs to reside in a common place (so that Beast or URL don't need to depend on JSON for the string_view because it's nothing to do with JSON.) So here we are. (Incidentally, the new and improved string_view is also faster on a number of benchmarks I did, and can be made faster still.)
Otherwise, introducing as a separate library and letting the community decide what is better (with review and then with usage) seems like the way to go.
I'm not really sure that this is a path that leads us where we want to end up. We want the boost string_view type to be called boost::string_view, and not boost::strview2::string_view. Adding a new library doesn't seem to me to be the best way to achieve that goal, although I suppose it's possible to end up there taking this detour as well. But more importantly, while this new library is getting through the review cycle, JSON et al can't use it, and we need them to try to use it in order for us to have confidence that we want this library at all.
Preemptively putting it in Boost.Core feels like bypassing community choice, which goes against the spirit of Boost.
Correct but doesn't really help anyone. At this point, what I think we can do is for me to move boost::core::string_view to boost::core::detail::string_view and remove it from the public Core documentation. It might seem a bit stupid to remove documentation that's already written, but it's probably better for it to not be exposed to users yet so that they don't start depending on it. Meanwhile, JSON and friends can try using it and we'll see what comes out of that.