Proposal: Hide the int in opApply from the user

[BC]

On Wed, 09 Jan 2008 21:15:48 -0000, bearophile <bearophileHUGS at lycos.com>  
wrote:

> Paul Findlay Wrote:
>> This is an old (1993), but I hope related, discussion:
>> Iterators: Signs of Weakness in Object-Oriented Languages
>> http://home.pipeline.com/~hbaker1/Iterator.html
>
> Thank you for the link, it's quite interesting.
> From that article:
>
>> Iterator functions for a collection can be "member functions" of the  
>> C++ collection class itself, but this policy creates a problem if one  
>> wishes to enumerate the same collection for different purposes at the  
>> same time--e.g., if one wishes to enumerate the Cartesian product of a  
>> collection with itself. The problem is that the "state" of the iterator  
>> must be stored somewhere, and the only two places are in the instance  
>> of the collection or the class of the collection. If the state is  
>> stored in the class, then only one iterator can be active for the  
>> entire class, while if the state is stored in the instance, then only  
>> one iterator can be active for the collection. Neither of these  
>> policies provides the flexibility required for our Cartesian product  
>> problem. The solution usually proposed for C++ is to provide every  
>> collection class with a "friend" class called its "iterator class".<
>
> If you put a D opApply as a metod of a collection class, it allows you  
> to enumerate the Cartesian product of a collection with itself too.
>
> Bye,
> bearophile

It's difficult to iterate over two collections without buffering.
A tree iterator needs a tree with parent links on all the nodes or it
needs to hold its own stack. Unfortunately if you try to assign those
iterators around, the stack is copied by reference and your program
is broken. So you have to explicitly dup those iterators in all your
generic code.