Re: Opinions on introduction of string_view in Core

From: Gavin Lambert (boost_at_[hidden])
Date: 2021-10-20 01:08:21

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.