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