12 Dec
2025
12 Dec
'25
9:30 p.m.
On 12 Dec 2025 23:23, Peter Dimov via Boost wrote: > Rainer Deyke wrote: >> On 12/11/25 20:44, Vinnie Falco via Boost wrote: >>> On Sun, Nov 16, 2025 at 6:48 PM Braden Ganetsky via Boost < >>> boost@lists.boost.org> wrote: >>> >>>> ... >>> >>> >>> Now that the release is over with I'd like to get back to this >>> conversation. I believe there is enough smoke / friction here that >>> warrants a resolution. I would like to see: >>> >>> * Only one string_view in Boost >>> * In a public directory (not detail) >>> * Strong interop with std::string_view >> As I understand it, this is a political problem. >> - boost::string_view has already been accepted into Boost. >> - Community consensus is overwhelmingly that it should interop better with >> std::string_view, but its maintainer doesn't want to make that change. >> - There is no process for forcing the maintainer to make that change. >> - There is no process for forcibly replacing the maintainer. >> - There is no process for removing the library from Boost and replacing it >> with another string_view library. > > Placing the blame solely there is not entirely fair. > > There's a reasonably straightforward process to follow and it's > > 1. make boost::core::string_view public > 2. make boost::string_view an alias for it This could work if boost::core::string_view and boost::string_view were compatible, but they are not. > but when we try to do (1) there're always complaints that "users will be > confused by these two different string_view classes"... as if users aren't > already confused enough by (a) already having two different string_view > classes _and_ (b) one of them being undocumented. For users, boost::core::string_view should not exist. At least, that's how I understand it should be.