+1 from me for drop as well, as I come from a functional background. Renaming until -> takeUntil makes sense, but renaming find is silly.
--- Cristi Cobzarenco BSc in Artificial Intelligence and Computer Science University of Edinburgh Profile: http://www.google.com/profiles/cristi.cobzarenco On 16 August 2011 11:27, Dmitry Olshansky <[email protected]> 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() > > 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.) >> >> Also, >> because it doesn't take the range by reference (unlike $(LREF >> popFrontN)), >> you can pass the results of other functions to it directly. But that >> also >> means that it does not affect the original range as long as it's a >> value >> type, which may or may not be what you want, depending on what you're >> doing. >> >> Examples: >> -------------------- >> assert(drop([0, 2, 1, 5, 0, 3], 3) == [5, 0, 3]); >> assert(drop("hello world", 6) == "world"); >> assert(drop("hello world", 50).empty); >> assert(equal(drop(take("hello world", 6), 3), "lo ")); >> -------------------- >> +/ >> >> - Jonathan M Davis > > > -- > Dmitry Olshansky > >
