Re: Opinions on introduction of string_view in Core

From: Gavin Lambert (boost_at_[hidden])
Date: 2021-10-21 00:11:41

On 21/10/2021 11:19, Bjorn Reese wrote:
>  Â Â Â Â Â Â Â  constexpr string_mediator(std::string_view other) noexcept
>  Â Â Â Â Â Â Â Â Â Â Â  : data(other.data()), size(other.size()) {}
> 
>  Â Â Â Â Â Â Â  constexpr string_mediator(boost::string_view other) noexcept
>  Â Â Â Â Â Â Â Â Â Â  : data(other.data()), size(other.size()) {}

Also, it's not quite this straightforward -- since both of these are 
also implicitly constructable from char pointers and std::strings, you 
have to add constructor overloads for these conversions too, otherwise 
it's more annoying for the consumer.

(Even if the compiler permitted two consecutive implicit conversions, 
which it doesn't, that would be ambiguous in this case -- which is *why* 
it doesn't.)

It's relatively trivial to add these extra constructors as well, 
although the end result is that you've almost entirely duplicated the 
implementation of string_view anyway, just without the string-like 
convenience methods (which may also be annoying for the consumer).

Having the wrapper inherit from one of the two (naturally, this has to 
be boost::string_view) fixes both of these problems and reduces the 
amount of code required (as I think Peter suggested himself at one 
point).  It also more clearly indicates which operations are "missing" 
from boost::string_view.  I don't recall why he didn't like this option 
either, other than "I already wrote the full replacement" (implied, not 
quoted).