Re: Opinions on introduction of string_view in Core

From: Peter Dimov (pdimov_at_[hidden])
Date: 2021-10-18 23:18:41

Gavin Lambert wrote:
> On 19/10/2021 03:34, Peter Dimov wrote:
> > So yes, having two string views may be bad, but the alternative is
> > having four of five.
> 
> Those are not the only options.
> 
> Another possibility is to define a boost::any_string_view which is *not* a
> clone of {std,boost}::string_view but just does conversion duck-typing
> boilerplate (i.e. it defines no methods of its own other than conversions, and
> the only useful thing you can do with one is to assign it to a
> {std,boost,other}::string_view).
> 
> Ideally, this is what would appear in Boost.Core.

That's an option, yes. It's not clear why you think that's a better option, though.
You get all the costs of the implicitly convertible thing, and none of the benefits
of it being a string_view.

Maybe because you think that administratively, it would be easier to sneak into
Core without a review? But that's actually not true, because a component that
is a portable implementation of a C++17 thing and which therefore has its
interface already specified in the standard has a better claim to Core than a
novel component.

> This is somewhat auto-hostile, but that's not unprecedented (Boost.Units is
> also auto-hostile).

Auto-hostile, and doesn't allow things like f().starts_with("http:"), or f() == "foo".

That's a common theme with all alternative suggestions so far - they make
user experience worse for no good reason apart from red tape.