Re: [boost] Opinions on introduction of string_view in Core

On 10/18/21 5:21 AM, Vinnie Falco wrote:

On Sun, Oct 17, 2021 at 6:21 PM Andrey Semashev via Boost 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.