opApply Vs. Ranges: What should take precedence?

[dsimcha]

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.