Implementations of takeWhile, drop, and dropWhile.

[jmdavis]

This fulfills http://d.puremagic.com/issues/show_bug.cgi?id=4535 and partially fulfills http://d.puremagic.com/issues/show_bug.cgi?id=5645

drop and dropWhile in particular should help allow a more functional style of programming when dealing with ranges.

[kennytm]

@property? (pure nothrow const @safe too, if you like :) )

[jmdavis]

You're right. I forgot @Property, and I can put const on it, but I can't put pure, nothrow, or @safe on it because that depends on the range being passed in. Those will have to be inferred.

[kennytm]

return _done; is pure nothrow @safe no matter if the range's annotation. But you're right, it's better to let the compiler infer that.

[jmdavis]

Any more comments on this before I merge it in?

[jmdavis]

Any more comments, suggestions, or objections? I'd like to merge this in as it stands, and Andrei now seems to be okay with takeWhile being added to Phobos, which appears to have been his main objection. drop borders on a necessity IMHO, since it's a huge boon for functional-style programming, and if we have drop and takeWhile, then it makes sense to have dropWhile. So, it seems to me that they should all be added to Phobos, but I don't want to merge them and then have complaints about it, and it's not entirely clear to me that everyone's concerns about these have been addressed.

So, does anyone have a good reason as to why any of these shouldn't be merged into Phobos?

[andralex]

Upon looking at this again, I think this addition doesn't pull its weight. takeWhile is isomorphic with until, drop is a lossy version of popFrontN, and dropWhile is isomorphic with find. Jonathan, that's not to diminish your work -- sorry. You may want to put this up for a community vote or something. My opinion is that we don't need such redundancy in std.algorithm.

[jmdavis]

Well, if you can do exactly the same thing as takeWhile and dropWhile with until and find, then I think that there are solid arguments for not adding them. However, as far as I know, ou can't do the same thing as drop with anything else. popFrontN can't be used in an expression while drop can. drop is really useful when chaining functions together in way that popFrontN can't be.

So, if you really think that takeWhile and dropWhile don't pull their weight, then I can live with that. Other functions can be made to do the same thing fairly easily. But the same isn't true for drop. So, if you really don't think that drop is worth adding, then I guess that I'll have to go for a community vote on that one. I can live without having takeWhile or dropWhile, but it's very annoying not to have drop, since popFrontN just be used in a functional style.

[andralex]

You may want to ask for a vote on drop. I'd use (popFrontN(r), r) for doing what drop does, and overall I prefer popFrontN because it returns the number of elements popped - information which is lost with drop.

[jmdavis]

I'll ask for a vote on it then. (popFrontN(r), r) is a solution that I'd never thought of, but then again I never use the comma operator aside from the 3rd portion of a for loop, and I believe that most programmers agree with me an that one. Regardless, there's no point in keeping this pull request open. I'd need to redo it to just have drop anyway.

On a related note, we might want to look at how we can improve the documentation to make it clearer as to what functions can be used to do the same thing that other languages do. For instance, reduce already mentions foldl. Perhaps until and find should mention takeWhile and dropWhile. It's not entirely uncommon for someone to think that there's no function in Phobos which does what they want simply because none of them have a name that they recognize as doing what they want. It's not an entirely solvable problem, but we can probably find ways to improve the situation.