Input ranges

[via Digitalmars-d-learn]

On Sunday, 19 April 2015 at 11:33:26 UTC, anonymous wrote:
> I guess the problem is the mix of value and reference 
> semantics. ByRecord's `current` is a value, but its `file` has 
> reference semantics. So, a copy of a ByRecord affects one part 
> of the original but not the other.

I agree. Yet I am convinced most (all?) proper input ranges read 
input from an external source. (Reference semantic right there.) 
Input ranges are one-pass ranges after all. Therefore, reference 
semantics are required in any case (unless the use of the range 
is known beforehand.)

groupBy is a nice example as it laboriously adds reference 
semantics to forward ranges but assumes input ranges to posses 
reference semantics by themselves.

> Maybe copying should be `@disable`d for such ranges/structs. 
> Then you couldn't pass it by value to groupBy. Instead you 
> would have to use something like (the fixed version of) 
> refRange, which works properly.

Again, I agree. Disallow copying for such ranges would prevent 
the error, still it would be a bit harsh. It is not just groupBy 
that goes astray. You can also get strange results from take:

     auto r = File("test.txt").byRecord!string("%s");
     foreach (i; 0 .. 5)
         writeln(r.take(4).map!(a => a[0]));

I was hoping to find some communication how input ranges should 
be done. At this point the solution in byLineCopy feels ad hoc.