Should we add drop to Phobos?

[Jonathan M Davis]

On Sunday, August 14, 2011 13:09:59 Timon Gehr wrote:
> +1. Having take but not drop does not add to the beauty of the module.
> I'm also strongly in favor of adding dropWhile, dropUntil and takeWhile,
> plus renaming std.algorithm.until to takeUntil. "until" is an
> undescriptive name and it has a different meaning in functional
> programming language libraries.

Renaming until takeUntil might be a good idea, though you'd have to talk 
Andrei into it.

However, dropWhile isn't going to make it in because it's the same as find 
except that predicate is reversed. All you have to do is use std.function.not 
on your predicate to find, and you have dropWhile. The same goes for takeWhile, 
except that it's std.algorithm.until which does the same thing aside from the 
reversed predicate. And dropUntil _is_ find, no reversing of predicates 
required.

There was a fair bit of discussion about this in

https://github.com/D-Programming-Language/phobos/pull/147

While I rather like the idea of having takeWhile and dropWhile, Andrei's 
stance is that because they do the same thing as existing functions except for 
the reversed predicate, they shouldn't be added. And while I'm not entirely 
happy with that, I think that he has a very good point. We don't want to 
clutter Phobos with functions which do the same things as other functions.

So, I could see an argument for renaming until to takeUntil. I don't know if 
Andrei would go for that or not, but that could be reasonble. I certainly 
agree that the name would be better. However, dropWhile, dropUntil, and 
takeWhile aren't going to make it in because we already have functions which 
already do the same thing with at most requiring that you reverse the 
predicate.

drop, on the other hand, I'd argue adds much more value. You can't do drop 
with any other function in Phobos. The closest that you get is Andrei's 
suggestion of (popFrontN(range, n), range) which while clever, is fairly 
hideous IMHO given that it uses the comma operator. So, drop adds signicant 
benefit towards a more functional style of programming, whereas the others just 
make it so that you don't have to mess with your predicates as much to do what 
you want - which would be nice but not nice enough to clutter the standard 
library with.

- Jonathan M Davis