Should we add drop to Phobos?

[Daniel Murphy]

"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.2378.1313523921.14074.digitalmars-d at puremagic.com...
> On Wednesday, August 17, 2011 01:23:18 Daniel Murphy wrote:
>> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
>> news:mailman.2361.1313462679.14074.digitalmars-d at puremagic.com...
>>
>> > They already exist:
>> >
>> > dropUntil == find
>> > dropWhile == !find (i.e. same thing, but the predicate must be negated)
>> > takeUntil == until
>> > takeWhile == !until
>>
>> I'd prefer to have all of these available in phobos.
>>
>> > Andrei is against adding functions which are functionally identical to
>> > existing functions save for the negation of the predicate, and he's
>> > definitely
>> > against adding aliases. To some extent, I'd like to have functions 
>> > which
>> > are
>> > functionally identical save for the negation of the predicate, because 
>> > I
>> > think
>> > that it makes for clearer, neater code, but I think that he has a very
>> > good
>> > point in that we don't want to clutter Phobos with functions which are
>> > nearly
>> > identical. New functions must add something of definite value to be
>> > worth
>> > adding.
>>
>> I think one argument that is often used to argue for more features in the
>> language applies here - less functions makes for a cleaner phobos, but
>> messier user code.
>>
>> eg:
>> dropWhile!predicate(r) vs find!(Not!predicate)(r)
>> The second version is noisier, requires extra parentheses, and requires 
>> an
>> import of std.functional whenever it's used.
>> Won't these end up as simple aliases in phobos?
>>
>> Disclaimer: I haven't read the github discussion.
>
> Ultimately, Andrei's argument against having a function like dropWhile 
> when we
> already have find is that the new function doesn't really add any new
> functionality. All you have to do is negate the predicate, and what we 
> have
> already works. Adding new functions which do essentially the same thing is
> therefore just cluttering up the library. On some level, I agree, and on 
> some
> level I don't.
>
> Regardless of that, however, we've already agreed previously that Phobos 
> won't
> have aliases simply to give alternate names for functions. So, even if you
> could talk Andrei into a function like dropWhile or takeWhile, you're 
> never
> going to see something like dropUntil, because it would be a pure alias.
> _Maybe_ you could get it if you argued for replacing the version of find 
> which
> takes just a predicate and a single range with dropUntil, but a simple 
> alias
> is agaisnt the Phobos coding standards. Those are pretty much just used as
> part of the deprecation process.
>
> If you want to argue that dropUntil, dropWhile, takeUntil, and takeWhile
> should be added to Phobos, feel free to start a new thread on it, but 
> Andrei
> is against it, and it's already been discussed a fair bit in that pull 
> request
> (so, I'd advise reading that before posting a new thread on the issue). 
> And
> regardless, I don't think that it's a good idea to bring it up before the
> issue of drop has been addressed. Andrei is already against drop, and that
> should arguably be a shoe-in. Fortunately, assuming that there's actually
> community support for it, he's willing for it to be added.
>
> So, drop may be added, but you're going to have to come up with some very
> well-written, objective arguments for why the others should be added if 
> you're
> going to stand any chance of convincing Andrei, and I'd wait on discussing 
> it
> until drop is in, since if we can't even get drop in, we're sure not 
> getting
> the others in.
>
> - Jonathan M Davis

This is basically what I assumed.  While I do have a perference, I don't 
feel strongly enough about it to push for a change here.  It has also been a 
couple of years since I've heavily used the range-manipulation functions in 
phobos.

As you've said, drop adds functionality that isn't available elsewhere, so 
I'd like to see it available in phobos.  (+1)