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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2024-02-14 23:38:17

g.peterhoff--- wrote:
> Have you come to a conclusion how this should be handled (in the future)?
> 
> The problem is basically that there are different implementations for
> string_view.
> I don't know why it was done this way.

The motivation for creating boost::core::string_view was that there exist
several pre-C++17 Boost libraries that want to take and return string views
as parameters and return values.

This is a problem because C++17 users prefer to use std::string_view.

These libraries used to offer a configuration macro that switched between
boost::string_view and std::string_view (e.g.
BOOST_LIBNAME_USE_STD_STRING_VIEW.)

But this is also a problem because, since these libraries are compiled, users
of precompiled libraries get one or the other. Their defining the macro
cannot affect how the library has been built.

That is why I created boost::core::string_view, which is a string view type
that is also convertible from and to std::string_view. So the library API can
be

boost::core::string_view api_function( boost::core::string_view key );

but C++17 users can both pass std::string_view to it and store the return
value into std::string_view.

There have been attempts to add these conversions to boost::string_view,
but those have been rejected by the maintainer.

When I tried to add boost::core::string_view to Core as a documented and
public component, people here objected. So it's not documented and public
now. Hope those people are happy for heroically preventing components
from being documented.

So we are where we are.