http://d.puremagic.com/issues/show_bug.cgi?id=4264
David Simcha <[email protected]> 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 <[email protected]> 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: -------
