Feasibility of std.range and std.algorithm in D 1.0

[Brian Palmer]

I'm really excited about where std.range is headed, it feels like a fundamentally better concept to me than STL iterators. I also do a lot of Haskell, so the similarities I see there are very exciting. I feel fortunate in that I and some of my co-workers get to use D 1.0 for work, but it's apparent that it will be a very long time (in software terms) before we can switch to 2.0. And I'm perfectly OK with this, a lot of very, very good stuff is going into 2.0 and I don't want it rushed.

Last night I started playing with the idea of doing a partial back-port of std.range to D 1.0. After hacking on it for a few hours, I came up with something that, from the end-user's standpoint, is very similar. It only works in the newest dmd and in ldc, because of the need for partial IFTI. For instance, this example from the ddoc works without change:

assert(equal(take(5, cycle([1, 2][])), [ 1, 2, 1, 2, 1 ][]));

So far I've implemented take, drop, cycle, chain, map, filter, inPlace and find. However implementing a Range is more difficult than in 2.0, and performance suffers somewhat. There are two main reasons for this: no ref functions (which I've always thought a bizarre oversight), and no foreach range support. Both could be implemented in a backwards-compatible way for 1.0, but as I understand it the official stance is only bug fixes in 1.0 going forward. So is there any chance at all of having these changes implemented? Even if not, does this port interest anybody else? We aren't really satisfied with the container/iterator libraries available for 1.0 so we'll likely pursue this route.

The git repo for the code isn't public yet, so I've uploaded a snapshot zip for the curious and/or bored. Be warned, late-night hacky code ahead.

http://www.codekitchen.net/ranges_and_algorithms.zip