On Mon, Oct 18, 2021 at 7:19 AM Marshall Clow via Boost
I have two concerns here, one technical and one philosophical.
The first one is, as Peter has said, is implicit conversions. Specifically, introducing ambiguity. We had to resolve ~10 ambiguous cases when we added string_view to the standard library. Adding a 3rd type into the mix will almost certainly add new ones.
Yeah and that's why we need this new string_view to go into core, protestations against the lack of formal review notwithstanding. So we can sort out these conversions.
The second one is about the long term use of boost::string_view. My opinion is that it is a transitional library, useful for people on older systems which do not have std::string_view. All things being equal, we (boost) should be encouraging people to transition away from boost::string_view to std::string_view when they can.
Equivalent to saying that "we (boost) should be encouraging people to transition away from C++11 in favor of C++17." Until C++11 has less than 5% of the market, I certainly can't be requiring C++17 for any of my libraries. And as of the latest language survey, C++11 is still firmly ensconced as a Very Popular Version of the language. This leaves us with a big problem. We are encountering headwinds evolving a component that is vital for existing C++11 libraries.
[ Note that I don’t think that’s necessarily true for boost::shared_ptr which has additional functionality above and beyond std::shared_ptr. ]
The set of use-cases for string_view is considerably larger than the set of use-cases for shared_ptr in argument lists. Furthermore std::shared_ptr is available in C++11 (which realistically is the minimum that new libraries should target). Thanks