Jonathan M Davis wrote: > On Tuesday, October 16, 2012 10:58:23 David Gileadi wrote: > > On 10/16/12 10:28 AM, Jonathan M Davis wrote: > > > Any range is free to violate this, but because range-based functions are > > > free to rely on it, such ranges risk not working correctly with many > > > range-based functions and must be used with caution. > > > > As a D dabbler, it seems wrong to me that a built-in range like byLine, > > which is often used in example code, should have weird side effects with > > the built-in methods in std.algorithm. IMO this needs to be fixed one > > way or another, and a mere documentation change is likely not enough for > > casual D users. > > ByLine needs to do what it does for performance reasons, so its > implementation > makes a lot of sense, and it really wouldn't make sense for it to do what > would be necessary to make it work as a normal range (since that would mean > allocating a new buffer for every line), so if the fact that it's likely to > be > used and then misused by newbies is a big problem, then that's a strong > argument for making it just use opApply rather than being a proper range. I > certainly don't think that it makes sense to change how ranges work in > general > just to better support ByLine's weirdness. it would be far too restrictive to > do so.
I've not really looked at byLine. Why do you have to do an allocation for each line? byChunk seems to not suffer from this problem (see http://d.puremagic.com/issues/show_bug.cgi?id=8085). Does this mean byChunk is less efficient? I want to add that if byLine only implements opApply, then there should be some adapter that turns anything which has an opApply into a range. Then you have to do: byLine().adapter().joiner(). And I also think that the documentation needs to clarify whether popFront may invalidate t, if t was obtained before via auto t = r.front. Jens