Algorithms & opApply

[dsimcha]

== Quote from bearophile (bearophileHUGS at lycos.com)'s article
> The gentle and a-lot-working David Simcha has converted one of my bug reports
into an enhancement request:
> http://d.puremagic.com/issues/show_bug.cgi?id=4264
> Currently (SVN) only array() is able to digest iterables that define opApply
only, but I think a few more spread support will be very good.
> In the thread of that 4264 there are plenty of comments and views of the
situation. Opinions welcome, both here and there.
> Bye,
> bearophile

This one didn't get much attention, possibly because the bug report is too long,
too complicated and too indirect.  Let me reiterate the basic points inline.

I've been working heavily on debugging and polishing std.range and std.algorithm.
 (I've fixed 14 Bugzilla bugs plus several unlisted bugs and enhancements in these
modules since last DMD release.)  One issue that's been nagging me for a while,
and has apparently been nagging Bearophile, too is that opApply-based objects are
not supported at all, even where supporting them would be completely feasible.
Examples are std.algorithm.map, std.algorithm.filter and std.algorithm.chain.  I'm
thinking of generalizing std.range and std.algorithm to work with any foreach-able
object where possible, including opApply-based iteration.  My concerns are:

1.  Bug 2443 makes it impossible to propagate ref to higher order objects correctly.

2.  Building higher order iterables with opApply might get so slow that it's
virtually unusable, due to multiple layers of delegate calls.  Then again, this
might be premature optimization for a dumb compiler, as LDC can inline through at
least one level of opApply delegate calls.  I haven't tested to see if it can do
more than this.

3.  Ranges are the flagship way of iterating through an object in D, as they
should be.  opApply has its uses, but they're relatively few and far between.  I'm
wondering if anyone besides bearophile and I think supporting opApply is worth the
effort and potential bloat, if Walter cares enough to fix Bug 2443, and if Andrei
considers it to be a reasonable part of std.range/std.algorithm's design.