Re: Opinions on introduction of string_view in Core

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2021-10-17 22:27:01

On Sat, 16 Oct 2021 at 21:01, Peter Dimov via Boost <boost_at_[hidden]>
wrote:

> 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.

Is this not fixable by adding a std::string_view conversion operator to
boost::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.)
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
-- 
Richard Hodges
hodges.r_at_[hidden]
office: [phone]
home: [phone]
mobile: [phone]