Andrey Semashev wrote:
Though, honestly, I didn't quite understand the objection back then. It seemed, Marshall was under the impression that relying on BOOST_NO_CXX17_HDR_STRING_VIEW was problematic for some reason.
Adding implicit conversions in this case had the potential to create a lot of subtle issues because code exists that does all sorts of funny things such as having conversion operators to char const*, or std::string, or boost::string_view, or std::string_view, or having overload sets taking all possible combinations of those. So I understand his reluctance to commit to the potential maintenance burden created by that. That is why we went the route we went; adding a second string_view with those conversions, not maintained by Marshall, so that the potential issues would not have to be addressed by him (but by me.) Everything is not 100% fine, https://github.com/boostorg/core/issues/167 but it mostly is, so I'd say we're at a point where we can make boost::string_view what core::string_view is. Since Core is not allowed to depend on Utility, one possible approach is to define boost::string_view in Core, make boost::core::string_view a using declaration, and include that in Utility. Although if people insist on arbitrary Traits support, we probably need to do something else. (Kind of unrelated, I see that I never got around to adding the string_view benchmarks to the Core repo. So much to do, so little time.)