Re: Interest in updated, standalone iterator_facade library?

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2019-08-13 12:17:50

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.

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.

Regards, Phil.