Re: Opinions on introduction of string_view in Core

From: Gavin Lambert (boost_at_[hidden])
Date: 2021-10-18 00:33:19

On 18/10/2021 11:28, Peter Dimov wrote:
> Gavin Lambert wrote:
>> I would have less of a problem if the addition had been in another library (such
>> as Boost.StringView2) with clear deprecation of the one in Boost.Utility and
>> intent to remove in the future, ...
> 
> StringView2 works for me, but what exactly is the difference being sought? The
> only thing I see is that it will go through a review which will likely reject it.

The difference is the deprecation.

And if you think that a review would reject it, this suggests that it is 
not a good change.  (Duplicating existing functionality is not by itself 
grounds for rejection, although it does raise the hurdles.)

It might be easier to pass a review if it did more fully implement 
std::string_view's behaviour, where possible pre-C++17 (or documented 
justifications for not doing so).

>> Adding a "replacement" that is not a replacement to Boost.Core just seems like
>> the wrong thing to do, on multiple levels.
> 
> The alternative is for all libraries that need this string_view (such as JSON, the
> upcoming URL, Beast maybe) to contain their own private copy. Which is what
> Core has been designed to solve. Of course, the process is supposed to be for
> the private duplicate copies to appear first, then be moved into Core, so this is
> admittedly a bit of a shortcut.

That would be fine if boost::string_view did not already exist.  But it 
does.

The best choice seems to be to add the necessary conversions to the 
existing boost::string_view, rather than adding a new one.  It just 
seems like you're trying to do an end-run around this because you're 
having trouble convincing the maintainer that it's a good idea.  But 
unilaterally adding a conflicting type to an existing library without 
review and without deprecation of the old type is a worse idea.

Otherwise, introducing as a separate library and letting the community 
decide what is better (with review and then with usage) seems like the 
way to go.  Preemptively putting it in Boost.Core feels like bypassing 
community choice, which goes against the spirit of Boost.