Should we add drop to Phobos?

[Timon Gehr]

On 08/14/2011 01:29 PM, Jonathan M Davis wrote:
> 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.

I'd argue that find should actually have been called dropUntil. It is 
not evident at all what find does, given the name alone. If it is called 
dropUntil, nobody ever needs to read the documentation, be it the guy 
who writes the code or the guy who has to read it. But as it is probably 
heavily used, it is not sensible renaming it now. (and all I have to do 
is define an alias :))

>
> There was a fair bit of discussion about this in
>
> https://github.com/D-Programming-Language/phobos/pull/147

Ok, thanks. However I don't agree that the functions would clutter the 
standard library: In functional code, it is *crucial* for the 
understandability and ease of writing of code that it is not necessary 
to mess with predicates and it is possible to use a natural 
nomenclature. As things are now, if somebody wants to write 
functional-style D code, they have to implement a lot of the basic stuff 
themselves.

The discussion is basically between keeping it small and orthogonal 
(with imho questionable defaults) or making it large, flexible and 
convenient, without requiring the user to implement many small helper 
functions. I'm fine with defining my own utility functions, but I think 
if many people end up writing that functionality themselves, the std 
library has missed opportunities.

>
> 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.
closer:
((int n){auto s=range.save(); popFrontN(s,n); return s}(n))

> 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

Yes, drop should be added. But I think that using the comma operator is 
no more hideous than using something like:

until!(not!p1)(find!p2(range));

instead of

takeWhile!p1(dropUntil!p2)(range));