Re: Opinions on introduction of string_view in Core

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-10-18 11:38:30

On 10/18/21 5:21 AM, Vinnie Falco wrote:
> 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.

I'm not arguing that having the conversions in boost::string_view is a
better solution, I'm in favor of that change. I'm just trying to work
out a solution given that we don't have the conversion. Forking
boost::string_view does not like a solution to me.