Tricky semantics of ranges & potentially numerous Phobos bugs

[Jens Mueller]

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