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.