Re: Opinions on introduction of string_view in Core

From: Marshall Clow (mclow.lists_at_[hidden])
Date: 2021-10-18 14:18:47

On Oct 17, 2021, at 3:33 PM, Peter Dimov via Boost <boost_at_[hidden]> wrote:
> 
> Richard Hodges wrote:
>> Is this not fixable by adding a std::string_view conversion operator to
>> boost::string_view?
> 
> Yes it is. Marshall is opposed to adding implicit conversions - from, or to,
> std::string_view - to boost::string_view.
> 
> I understand this stance of his because implicit conversions are kind of a
> pain and a maintenance burden because new ambiguities will very likely
> keep popping up and need to be squashed. But what needs to be done,
> needs to be done.

I have two concerns here, one technical and one philosophical.

The first one is, as Peter has said, is implicit conversions. Specifically, introducing ambiguity.
We had to resolve ~10 ambiguous cases when we added string_view to the standard library. 
Adding a 3rd type into the mix will almost certainly add new ones.

The second one is about the long term use of boost::string_view.
My opinion is that it is a transitional library, useful for people on older systems which do not have std::string_view.
All things being equal, we (boost) should be encouraging people to transition away from boost::string_view to std::string_view when they can.
[ Note that I don’t think that’s necessarily true for boost::shared_ptr, which has additional functionality above and beyond std::shared_ptr. ]

On the other hand, boost::string_view has additional functionality w.r.t std::string_view, because of some odd (to me) choices by the standard committee (removing comparisons, for example).

— Marshall