I was playing around with dcollections today and it reminded me of a subtle unresolved issue. This has been brought up here before, but always buried deep in some other thread. I think it deserves its own thread for some serious debate.
What should take precedence when a class or struct defines both a range interface and an opApply with one variable? My vote is for opApply to take precedence for the following reasons: 1. In general, if someone defines a range interface, and then also defines an opApply interface, they probably have a good reason for doing so, since ranges provide a superset of opApply functionality. 2. Some things can't be iterated over as efficiently w/o control of the call stack. For example, iterating over trees w/ control of the call stack is easy and efficient. Iterating without control of the call stack requires a heap allocation for an explicit stack. 3. opApply can be more efficient than ranges if the range functions (front, popFront, empty) are virtual. For runtime polymorphic class objects, it may make sense to provide opApply as an optimization, even if the semantics are the same as range-based foreach.