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.