On Mon, 20 Apr 2020 at 11:01, Lyberta via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:
>
> Barry Revzin via Std-Proposals:
> > It's actually somewhat worse than this. span used to have comparison
> > operators, and then people fought to remove them.
>
> Because it should be shallow comparison or no comparison at all. span is like a "fat" pointer, it doesn't own the data and data
> can change at any time. Having deep comparisons would make a lot of very unsafe code compile.
>
> I would say that std::basic_string_view should also have its comparison operators removed for the same reason.
I've been happily using these "unsafe" comparisons for years without issue. It's quite nice having those comparisons. The ratio of problems with span relating to dangling vs problems with span relating to unexpected comparisons is surely 1, to within rounding error.
That "unsafe code" will compile anyway, you've just made it
inconvenient to write - we need to use a compare() function
as opposed to just using operator==. Also, by that definition,
references and pointers are similarly unsafe, and comparison
through them are surely banned in this wonderful Regular World that is
next to unusable.
A major use case for span and string_view is parsing - get a sub-range
to something, compare it like it's a whole
range. But noooooo, in a Regular Dogma that use case is not accepted.
You may not be able to add at() externally as a member function, but at least with the comparisons you can be naughty and just stash them in namespace std anyway - so if someone were to go ahead and implement them, you could just include a header and voila:
Barry