multiple-item traversal ranges

[Jonathan M Davis]

On 2011-03-30 11:22, dsimcha wrote:
> == Quote from spir (denis.spir at gmail.com)'s article
> 
> > On 03/30/2011 05:03 PM, Andrej Mitrovic wrote:
> > > Doesn't opApply provide this?
> > 
> > Yes, but using opApply seems discouraged (scheduled for deprecation?).
> 
> opApply is less composable, and in current implementations, less efficient
> than ranges.  However, it is **_NOT_** going anywhere, since both internal
> and external iteration have their advantages.  opApply and the tradeoff
> between internal and external iteration are documented in TDPL.  An
> example of this is that iterating over trees is hard to express with
> ranges, because it requires an explicit stack. With opApply it can be
> written as recursion.
> 
> > And
> > opApply doesn't allow playing with other parts of "new style D" (esp
> > algorithms).
> 
> IMHO it should where possible, but a few bugs in opApply prevent me from
> fixing this.  Phobos should recognize "Iterables", or any type that can be
> iterated with a single-argument foreach.  Input ranges are a subtype of
> iterables.  Eventually std.algorithm should treat iterables as a supertype
> of ranges and things like map and filter should work.

See: http://d.puremagic.com/issues/show_bug.cgi?id=5691

Andrei is currently against making range-based functions work with opApply 
because of the resulting increase complexity of the implementations. They were 
really meant for ranges, not opApply. That doesn't necessarily mean that it's 
a guaranteed "we don't want to do it," but it's definitely questionable.

- Jonathan M Davis