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.