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.
