Andrey Semashev wrote:
I was initially against introduction core::string_view because I thought this would happen, and it did. Libraries now just have to support one more string_view in their interfaces. My hope was that at least the libraries would mention a concept of string_view in their documentation instead of exposing the mess we have internally, so that users would only deal with std::string_view or boost::string_view, whichever they choose for themselves. But apparently that didn't happen either, and some libraries documented or referenced core::string_view.
It didn't happen because it's impossible. You can't return a concept from a function, you have to return a specific type. Neither can this type be chosen by the user, especially for compiled libraries. We've been over all of this before; this is precisely why core::string_view exists, to be that type returned from library functions while still allowing the user the choice of assigning the result to whatever string_view type he prefers.
I already said what I think should be done. Make a proposal to keep just one string_view in Boost. Whether that is core::string_view or boost::string_view, I don't really care at this point. Then the community reviews that proposal. Then, if it's accepted, we act on it.
I'm not going to be the one writing this proposal, because, contrary to your insinuations, I don't actually have an opinion on how we need to proceed with it (there are options, some of which harder than others), and neither do I see any particular problem with having two string_view classes in Boost. Since this problem will eventually go away on its own, I'm not particularly invested in solving it now. What I do have an opinion about is that core::string_view should be public and documented, because this solves an immediate problem for the library authors who currently use it in their public APIs (and for the users who encounter it). I'm perfectly willing to leave the rest to the maintainers of Utility, where boost::string_view resides.