On Sun, Aug 11, 2019 at 10:22 AM Zach Laine
On Sun, Aug 11, 2019 at 9:54 AM Francesco Guerrieri via Boost < boost@lists.boost.org> 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