Re: Opinions on introduction of string_view in Core

From: Peter Dimov (pdimov_at_[hidden])
Date: 2021-10-19 01:33:10

Andrey Semashev wrote:
> 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, ...

One option is

class string_view: public core::detail::string_view
{
public:

    using core::detail::string_view::string_view;
};

The other is to document the API in terms of the library typedef, and never
mention core or detail. (Which means no changes at all because the API is
already so documented.)

> 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.

This is not what we want. We want a converting string_view that is called
boost::string_view. The way to get it is to make a converting string_view so
that we demonstrate the viability of the idea, then make boost::string_view
be it.

Deriving the new string_view from the old one is not the best way to get
there, because it's not the same thing and its behavior in actual code will
be different.

Admittedly, the above "opaque typedef" is not the same thing either, but
it's closer in behavior to what core::string_view is now.