|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2021-10-16 19:00:53
Andrey Semashev wrote:
> 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
The scenario being addressed here is that of a Boost library that does not
require C++17, yet its users want to use std::string_view when interacting
with the library. That is, the library API is
string_view api_function( string_view str );
and some of the end users aren't on C++17 and will use the library-provided
string_view, and others are on C++17 and want to use std::string_view, both
to pass it as an argument to `api_function`, and to store its result.
Currently, if the library uses boost::string_view, it can't receive
std::string_view arguments. This is fixable by adding an additional overload
that takes a `std::string_view`, but other use cases now become ambiguous,
and need to be addressed separately either by yet more additional overloads,
or by templating some of the overloads, which is fragile.
And, this doesn't solve the problem of the return value. No matter what is
returned, some of the users will not be able to store the return value in their
preferred string_view.
A string_view type that converts from and to std::string_view solves this
problem, as the API above now works for both passing, and storing the result
into, `std::string_view`. boost::core::string_view is this type.
The alternative is for every library that has the above problem to supply its
own string_view, which will be a copy of boost::core::string_view. This is
exactly why Core was created - to factor out duplicate functionality.
(Before you suggest that the library should use boost::string_view under
C++14 and std::string_view under C++17, note that this makes it impossible
to build the library under C++14 and use it from C++17, which is a common
scenario when using the system-provided Boost package.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk