Re: Opinions on introduction of string_view in Core

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2021-10-20 02:45:56

On Mon, Oct 18, 2021 at 7:19 AM Marshall Clow via Boost
<boost_at_[hidden]> wrote:
> 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.

Yeah and that's why we need this new string_view to go into core,
protestations against the lack of formal review notwithstanding. So we
can sort out these conversions.

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

Equivalent to saying that "we (boost) should be encouraging people to
transition away from C++11 in favor of C++17." Until C++11 has less
than 5% of the market, I certainly can't be requiring C++17 for any of
my libraries. And as of the latest language survey, C++11 is still
firmly ensconced as a Very Popular Version of the language.

This leaves us with a big problem. We are encountering headwinds
evolving a component that is vital for existing C++11 libraries.

> [ Note that I don’t think that’s necessarily true for boost::shared_ptr
> which has additional functionality above and beyond std::shared_ptr. ]

The set of use-cases for string_view is considerably larger than the
set of use-cases for shared_ptr in argument lists. Furthermore
std::shared_ptr is available in C++11 (which realistically is the
minimum that new libraries should target).

Thanks