On Mon, Apr 20, 2020 at 4:13 AM Ville Voutilainen via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Mon, 20 Apr 2020 at 11:01, Lyberta via Std-Proposals
> <std-proposals_at_[hidden]> 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:

https://github.com/BRevzin/span_ext

Barry