Re: Interest in updated, standalone iterator_facade library?

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2019-08-12 15:46:01

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:
>
>> Hi, just to express my interest in this. I already have a legacy project
>> where this could be useful and if it were to land in boost (or in the
>> standard) it would be great. Thanks for doing this.
>>
>> 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:

https://github.com/tzlaine/iterator_facade/tree/interface_alternative

The one downside to this approach is that when you define operator++(), the
iterator_interface cannot define operator++(int) for you automatically,
because it gets hidden by the operator++() you just defined!  Oh, C++, I
wish I could quit you.  Anyway, I worked around this for now by just
keeping next() and prev(), and using operator*(), operator==(),
operator+=() and operator-() for the other operations.

I'm not super pleased with that, and I'm considering just using
operator++() and operator--() instead of next() and prev(), and requiring
the user to add "using operator++;" and/or "using operator--;".  This has
the nice property that if they forget, they'll get a compilation failure if
anyone tries to use post-incr-/decrement.  It has the bad property that it
is one more thing for the user to remember.  I'm certainly open to input
here.

So, there's your very large change.  You might give both approaches a try
and indicate which one feels more natural and why.

Zach