[Issue 4264] Support opApply in std.algorithm, std.range where possible

[d-bugmail at puremagic.com]

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


David Simcha <dsimcha at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |2443, 4707
            Summary|Various std.algorithm.map   |Support opApply in
                   |problems                    |std.algorithm, std.range
                   |                            |where possible
           Severity|normal                      |enhancement


--- Comment #7 from David Simcha <dsimcha at yahoo.com> 2010-08-21 19:54:17 PDT ---
Please disregard my last post.  I hit commit by accident when I was half-done
typing it.

Since everything you mention except the opApply issue is fixed either in 2.048
or in SVN, and the discussion has moved beyond Map to std.algorithm/std.range
in general, I've changed the name of this bug and made it into an enhancement
request.

I've thought about supporting opApply in some std.range and std.algorithm
types.  I think it's useful and conceptually feasible (ignoring implementation
minutiae) for at least the following, and probably more:

std.algorithm.map
std.algorithm.filter
std.algorithm.uniq
std.algorithm.until
std.range.chain
std.range.retro (if your object defines opApplyReverse)
std.range.stride
std.range.cycle

It's definitely not feasible for anything that requires random access or
manipulating multiple ranges in lockstep, backtracking other than to the
beginning of the iteration, or doing stuff with ranges of ranges (Transversal,
etc).

Here are some of the bigger issues I see at the implementation level:

1.  Bugs 2443, 4707 make dealing correctly with ref in the opApply case near
impossible.  I've made them blockers for this issue.  Even if these get fixed,
supporting ref correctly would be non-trivial enough that I don't want to
implement everything w/o ref support and then have to go back later and add ref
support.

2.  If we start building higher order iterables out of opApply, things could
become slow as molasses through multiple layers of delegate calls.  I know LDC
can inline these at least in simple cases, but what about when you have N > 1
levels of them?  

3.  This is a big enough change to the way std.range/std.algorithm work that I
think it needs to be discussed first, rather than just being checked in one day
like a bug fix or minor enhancement.  Maybe you should bring it up on the
newsgroup.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------