On 18/10/2021 15:21, Vinnie Falco wrote:
The easiest and most obviously correct solution is to change the existing boost::string_view or add a new boost::core::string_view to be seamlessly compatible with std::string_view. Period. All of this nonsense with writing templates, and SFINAE, and playing games with "returning the same thing as what was passed in" sounds nice on the Boost mailing list but it is not what users want.
To be clear: I do agree with the above. (Although Andrey's original post suggests that the current boost::core::string_view is *not* seamlessly compatible with std::string_view. I have not verified those concerns, but there'd need to be very good justification for it if so.) What I'm not clear on is the intended future of Boost.Utility's string_view. If the intent is as a "change of ownership" for maintenance purposes from Boost.Utility to Boost.Core, then the one in Boost.Utility should be immediately deprecated, and (if sufficiently compatible, immediately; otherwise in N boost releases) replaced with an alias typedef, then later removed entirely (at which point Core can add an alias from boost::string_view, but not before). If the intent is to introduce a new alternative implementation without cooperation from Boost.Utility, then it ought to be introduced via the proper formal review process, as if a new library (though it need not actually be implemented as such), so that the community can determine the merits. The result might end up the same as above, or the two might co-exist for longer until the users end up deciding. (To some extent this thread can be considered a kind of informal review, but it's likely less people are paying attention to it than would be the case for a formal review.) Or maybe the goal is to update the one in Boost.Utility instead of introducing a new one -- but that doesn't appear to be the case. It's long been a hole in Boost processes that new libraries require a formal peer review process but once over that hurdle, new functionality (including highly unrelated functionality, especially in a kitchen-sink library like Core) have no such requirement, instead relying solely on maintainers voluntarily requesting reviews or on people noticing commits and raising concerns (as in this case). There are reasons for this -- and I don't disagree with most of those -- but there is a line *somewhere* and I feel like this may have crossed it. I might be alone in this, but from the general tone of this thread, I don't think I am.