Should we add drop to Phobos?

[Jonathan M Davis]

On Tuesday, August 16, 2011 14:27:18 Dmitry Olshansky wrote:
> On 16.08.2011 6:33, Jonathan M Davis wrote:
> > On Tuesday, August 16, 2011 04:26:48 Martin Nowak wrote:
> >> I personally like immutable methods way better than a ref changing
> >> function like popFrontN.
> >> As you pointed out writing str.find(";").drop(2).find(";").drop(2) is
> >> cleaner than writing this with popFrontN.
> >> 
> >> Drop will have issues for input ranges.
> > 
> > No more than many range-based functions do. Yes, it'll alter the input,
> > that's to be expected with any range-based function that you pass an
> > input range to. drop could be made to take only a forward range, but
> > that seems unnecessarily limiting. You just have to be aware of the
> > fact that range-based functions always remove elements from input
> > ranges when they process them - either that or they don't work with
> > input ranges.
> > 
> >> Adding a ref count parameter overload to let you know how many
> >> elements
> >> were dropped/not dropped seems too messy. No idea for that one.
> > 
> > It's a tradeoff. And if you really want drop, you probably don't care
> > anyway, since what you'd be doing would be chaining functions. If you
> > really care, just use popFrontN.
> > 
> >> The documentation should clearly state that this offers similar
> >> functionality to popFrontN but it's purpose
> >> is to enable a different syntax so that people don't get completely
> >> confused.
> > 
> > It does. This is the ddoc comment that I have for it:
> > 
> > /++
> > 
> >      Pops $(D n) elements off of the given range and returns it. If
> >      the length of the given range is less than $(D n), then an
> >      empty range is returned. The original range is unaltered as
> >      long as it's a value type.
> 
> Shouldn't this be : "as long as it's not an Input range", for everything
> else there is this clanky .save()

No, I meant what it says. drop doesn't call save, so it'll work with input 
ranges. However, if you use a range which is a class with it, then it's going 
to alter the original range. Forward ranges which are value types will not 
have the original range affected, but both input ranges and forward ranges 
which are classes will. I should probably find a better way to say it though to 
make it clearer. I suspect that a fair bit of Phobos doesn't work properly 
with ranges which are classes though. It's often assumed that passing a range 
to a function means that the original won't be altered, which isn't 
necessarily true.

> Anyway speaking of drop, I like it and don't think it'll cause some
> confusion as long as it's documentation clearly shows reasons on  drop
> 
> vs popFront. And it does in the following statements:
> >      The main reason to use $(D drop) instead of $(LREF popFrontN)
> >      is so that you can pop elements off of a range and pass the
> >      resulting range to another range-based function in a single
> >      expression, allowing you to chain function calls. It allows
> >      for a more functional style of programming. However, this
> >      means that you don't know exactly how many elements were
> >      actually popped in
> How about "an efficient thing to do for all ranges" ---> "efficient for
> ranges in general"?
> 
> >      the case where the range had fewer than $(D n) elements
> >      (unless you got its length first, which isn't an efficient
> >      thing to do for all ranges).
> A little bit of repetition here (you already told it's used to pass
> results to functions,  etc.)

I'll tweak the language a bit. Thanks.

- Jonathan M Davis