On 2011-03-30 11:22, dsimcha wrote: > == Quote from spir ([email protected])'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
