opApply Vs. Ranges: What should take precedence?

[dsimcha]

== Quote from Steven Schveighoffer (schveiguy at yahoo.com)'s article
> On Sun, 15 Nov 2009 14:47:23 -0500, dsimcha <dsimcha at yahoo.com> wrote:
> > 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.
> This is only the case where ranges *can* implement foreach.  There are
> other reasons for opApply, for instance overloading, or having multiple
> indexes.
> > 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.
> Hm... I disagree here.  My Tree implementation iterates over all the
> elements without recursion.

Yes, but looking at your implementation, you have parent pointers, which are
necessary anyhow for RB trees.  This makes it easier.  If you aren't using an RB
tree, storing parent pointers counts as an inefficiency.  So does requiring a heap
allocation for an explicit stack every time a range object is created.

> To answer the original question -- opApply should be chosen, and this is
> not debatable.  There is only *one* purpose for opApply -- to hook onto
> foreach.  If you defined both opApply and equivalent range functions and
> range functions where chosen first, opApply would be wasted code.

Agreed.  I'm starting to think that this is enough of a slam-dunk to go in Bugzilla.

> If you want to debate whether opApply should even exist anymore, that is a
> valid debate, but I think that ranges need to be much more flexible in
> terms of foreach before that happens.

As I've said a few times before, I totally agree w/ you that, while the
functionality of opApply and ranges overlap, they have different enough goals and
design tradeoffs to both have a legitimate place in the language.