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.