Opinions on introduction of string_view in Core

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-10-16 18:17:32

Hi,

Recently, a new implementation of string_view was introduced in Boost.Core:

https://github.com/boostorg/core/blob/d5bd40e5280487fb29a108eb42e6c4f0bef690d8/include/boost/core/string_view.hpp

Most of you probably know there is also a string_view implementation in
Boost.Utility:

https://github.com/boostorg/utility/blob/05e0d1688dcfcd3fdd65bdb6884b7edd1ad2c93c/include/boost/utility/string_view.hpp

The main motivation for introducing the new implementation is adding
conversions to/from std::string_view, which were proposed to
Boost.Utility and rejected a while ago:

https://github.com/boostorg/utility/pull/51

Another notable deviation of boost::core::string_view from
std::string_view and boost::string_view is that it only accepts the
character type in template parameters and not char_traits. This choice
was made to simplify implementation.

I have concerns that introducing yet another string_view type (3rd in
Boost, after boost::string_ref and boost::string_view, not counting
std::string_view) is not good for the ecosystem and interoperability, as
this will require adding explicit support in some code bases. One
example that I readilly have is Boost.Log:

https://github.com/boostorg/log/blob/4c54e4ca4c31f18ce2e451e8d0abf88054242d57/include/boost/log/utility/formatting_ostream.hpp#L558-L710

std::string_view was supposed to make user's code simpler by removing
the need to provide a multitude of function overloads accepting string
arguments. boost::string_view (and boost::string_ref before it) was a
prototype implementation before introduction of std::string_view and
served a similar purpose. In the age with std::string_view,
boost::string_view is still useful as a drop-in replacement for
std::string_view to lower C++ requirements in libraries and projects,
like this:

  #if !defined(BOOST_NO_CXX17_HDR_STRING_VIEW)
  using std::basic_string_view;
  using std::string_view;

  using std::string_view;

  #else
  using boost::basic_string_view;

  using boost::string_view;

  using boost::string_view;

  #endif

Introducing boost::core::string_view, which is not a drop-in
replacement, does not make users' code simpler as it requires adding yet
another set of overloads and specializations to users' APIs.

I should stress that I'm not opposing because I don't want to make
changes to Boost.Log, I'm opposing because I don't think those changes
will be for the better, and because I view this as potentially
destructive to the wide adoption of one common string_view type (be it
std::string_view or boost::string_view, depending on the conventions
taken in the project) to accept string arguments.

Please, express your opinions on this matter, in particular:

- Do you think it is good/ok/bad to have yet another string_view in Boost?
- Is it ok that boost::core::string_view is not a drop-in replacement
for std::string_view? Should it be changed to be one?
- Should we, perhaps, do something with boost::string_view from
Boost.Utility? Deprecate?
- Should we reopen the discussion to add conversion to/from
std::string_view to boost::string_view, which led to this fork? Perhaps,
hold a vote to make this change as widely requested?
- Any other course of action or thoughts?

Thanks.

PS: This post was made after an initial discussion in this commit:

https://github.com/boostorg/core/commit/95924b1329da49e70c9c8485b87e066895db2d64