"Jonathan M Davis" <[email protected]> wrote in message news:[email protected]... > On Wednesday, August 17, 2011 01:23:18 Daniel Murphy wrote: >> "Jonathan M Davis" <[email protected]> wrote in message >> news:[email protected]... >> >> > 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)
