Re: Opinions on introduction of string_view in Core

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-10-19 01:13:26

On 10/19/21 1:55 AM, Peter Dimov via Boost wrote:
> 
> 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.

Having a detail component part of the API is kind of odd. How would you
document the APIs that would use boost::core::detail::string_view, and
how would you advise users to deal with it, e.g. when they accept it as
a returned value? I mean, if you don't document it, users won't be able
to use it as in your `f().starts_with("http:")` example.

As an idea, if the goal is to test and refine conversions in the sole
use case of passing arguments and returning values, then maybe that is
how this component should be advertised. Let's call it a
boost::string_arg, a type that is supposed to be only used as function
arguments and return types and that doesn't do anything but the
conversion to/from strings, while delegating everything else to
boost::string_view. Advise users to never use boost::string_arg (and
Boost libraries - to only use it in function arguments), and for regular
string operations use boost/std::string_view. Note that this would be a
public component.

On a practical level, boost::string_arg would derive from
boost::string_view and only implement conversions. When/if we're happy
with it, we can simply merge it with boost::string_view and make
boost::string_arg a deprecated typedef/alias. And yes, boost::string_arg
should be compatible with boost/std::string_view in terms of template
parameters for that to be possible.

There is an obvious problem with auto, and we're still at an impasse if
we end up not convincing Marshall to merge the conversions into
boost::string_view in the end, but at least we will have something less
ambiguous to users than having a dozen string view types.