Re: Interest in updated, standalone iterator_facade library?

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2019-08-13 18:02:09

On Tue, Aug 13, 2019 at 7:18 AM Phil Endecott via Boost <
boost_at_[hidden]> wrote:

> Zach Laine wrote:
> > On Mon, Aug 12, 2019 at 8:38 AM Phil Endecott via Boost <
> > boost_at_[hidden]> wrote:
> >
> >> Hans Dembinski wrote:
> >> > compare vs. distance_to
> >>
> >> This reminds me of an issue that I've found with the existing
> >> iterator_facade: sometimes I can magnitude-compare the iterators,
> >> but not report a distance.
> >>
> >> For example, a simple filter iterator can quickly tell whether A is
> >> before or after B by comparing the underlying iterators, but it cannot
> >> find the distance without applying its filter predicate to all the
> >> intermediate elements.
> >>
> >> Currently, operator< etc. in the facade are implemented by calling
> >> the user's distance_to which is inefficient in this case.  Your change
> >> of name to compare made me wonder if it is now expected only to return
> >> -1/0/+1, but that doesn't seem to be the case.
> >>
> >
> > I think this is out of scope for the library, simply because the library
> is
> > for making models of the C++20 iterator concepts.  An iterator like you
> > describe is not one of those -- an iterator that is not random access and
> > yet has operator<() may be useful to you in some situations, but it is
> not
> > useful for communicating capabilities to standard algorithms.
>
> I disagree.  If I try to use std::sort() or std::map<> with these
> iterators,
> they don't (IIUC) check the iterator category, but rather they just need
> operator< (or std::less?) to be defined.
>

std::map is a read herring.  It does not need operator< on iterators, only
on keys.

As for std::sort, the existence of operator< on iterators is not enough to
make this work.  For instance, sort is allowed to use offsets and
operator[] on your iterator, and yet there's no such thing.

These concepts exist for a reason, and I'm not interested in subverting
them.

> Yes I can add them myself, but adding all of <, <=, >, >= is,
> pre-spaceship,
> tedious and a little error-prone - exactly the sort of boilerplate code
> that
> iterator_facade is trying to help eliminate.
>

Right, but in the cases you mention you only need operator<, right?

Moreover, all the requirements on each concept are actually checked in the
std::ranges algorithms.  Only having operator< does not help you use
algorithms that require a random_access_iterator does not work if the
algorithm only uses operator<; the concept-checking machinery will still
error out if you don't meet the full concept.

Zach