Re: Should boost::core::string_view be made public?

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-02-08 11:54:21

On 2/8/24 14:45, Andrey Semashev wrote:
> On 2/8/24 14:28, Дмитрий Архипов via Boost wrote:
>> boost::core::string_view is a string_view implementation that (unlike
>> boost::string_view from Utility) can interconvert with
>> std::string_view. This functionality was necessary for Boost.JSON to
>> drop the standalone mode, because people who have access to C++17
>> prefer to use std::string_view wherever they can. At the time there
>> was no consensus on whether the type should be made public.
>>
>> Now in addition to Boost.JSON the type is also used at least by
>> Boost.URL. And recently added Charconv is also using it. So, I want to
>> raise the question again: should we make the type public and refer to
>> it directly in our libraries' docs, rather than considering it an
>> implementation detail?
> 
> I think, if boost::core::string_view is to become public, it should come
> along with deprecating and then removing boost::string_view from
> Boost.Utility. As well as boost::string_ref. Having three string_view
> classes (if you count boost::string_ref, four if you count
> std::string_view) is a real problem for interoperability.
>
> This is assuming the two implementations are compatible in terms of
> interface and behavior.

Which they are not, as boost::core::string_view doesn't support
char_traits. So it looks like a non-starter to me.

> I'll add that this will not be a free transition for other libraries
> that support or use string views. For example, in Boost.Log I support
> boost::string_view and boost::string_ref but not
> boost::core::string_view. Not that it should be difficult to switch, but
> it's work. It's more complicated if the library or tool is unmaintained.
>