Proposal: Hide the int in opApply from the user

[bearophile]

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