Re: Opinions on introduction of string_view in Core

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2021-10-18 02:21:46

On Sun, Oct 17, 2021 at 6:21 PM Andrey Semashev via Boost
<boost_at_[hidden]> wrote:
> Perhaps you could present such use case and we can
> think how it could be improved.

The easiest and most obviously correct solution is to change the
existing boost::string_view or add a new boost::core::string_view to
be seamlessly compatible with std::string_view. Period. All of this
nonsense with writing templates, and SFINAE, and playing games with
"returning the same thing as what was passed in" sounds nice on the
Boost mailing list but it is not what users want.

C++17 users who choose C++11 Boost libraries are penalized in several
ways. Boost has its own pmr::memory_resource. Boost has its own
error_code. Boost has its own string_view. Even Boost flavored Asio
uses boost::error_code instead of std::error_code. This creates
friction for integrating Boost into existing C++17 code bases, a very
common user complaint. Requiring C++17 instead of C++11 for a Boost
library is obviously a non-starter since that cuts out an enormous
swathe of users.

If we want Boost to stay in the game, it has to adapt its offering to
be more friendly and seamless with std library vocabulary types. Peter
has already done much of this work, making boost::error_code
seamlessly interoperable with std::error_code (thanks for that!). Now
we need to do the same thing for string_view. Forcing N libraries to
change all their function signatures because we are allergic to having
a fork of Boost.Utilities' string_view is a losing strategy.

Thanks