Re: Interest in updated, standalone iterator_facade library?

From: Francesco Guerrieri (f.guerrieri_at_[hidden])
Date: 2019-08-12 16:57:44

On Mon, Aug 12, 2019 at 5:45 PM Zach Laine via Boost <boost_at_[hidden]>
wrote:

> On Sun, Aug 11, 2019 at 10:22 AM Zach Laine <whatwasthataddress_at_[hidden]>
> wrote:
>
> > On Sun, Aug 11, 2019 at 9:54 AM Francesco Guerrieri via Boost <
> > boost_at_[hidden]> wrote:
>
> >> Do you think that the code is already useable, or is there something
> "big"
> >> left to do? I hope to give it a try in some days and of course will
> report
> >> back to you if there is anything relevant or useful.
> >>
> >
> > I consider it to be ready, as-is.  There may be bugs lurking that need to
> > be fixed, but I don't know of any.  I can write every kind of iterator
> I've
> > ever needed to write (which is a lot).  This includes all the iterator
> > categories, plus proxy versions of each, and even weird stuff like
> > back_insert_iterator.
> >
>
> Yeah, about this statement.   I meant it yesterday when I made it.  Then I
> started investigating what it would take to make something like a
> range_facade, as was suggested earlier in this thread.  That lead me to
> discover std::view_interface, which I previously had never even heard of:
>
> http://eel.is/c++draft/view.interface
>
> It's pretty similar in concept to what iterator_facade does, but it does it
> using concept-based SFINAE on the members of std::view_interface, which
> leads to a small, easy-to-understand library interface, and a lot less
> library code.  It also allows the user to specify operations with their
> usual spellings, like operator*() instead of dereference().  It also does
> not require the access type, because you don't have to make functions with
> odd names that you want to hide.
>
> I like this a lot better.  In fact, I like it so much better that I
> implemented something like it yesterday on a branch, renaming
> iterator_facade to iterator_interface:
>
>
>
It is a large change but it is for the better, I like it a lot. The "using
operator++;" requirement is not too bad, it becomes mostly a matter of
documentation.

Thanks,
Francesco