Re: Opinions on introduction of string_view in Core

From: Peter Dimov (pdimov_at_[hidden])
Date: 2021-10-18 22:55:04

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.