On Sunday, 19 April 2015 at 21:42:23 UTC, Ulrich Küttler wrote:
groupBy is a nice example as it laboriously adds reference
semantics to forward ranges but assumes input ranges to posses
reference semantics by themselves.
All ranges are input ranges, though. Input ranges are the least
specialised category. I think it's a mistake to assume/require
anything only for input ranges that are not forward ranges.
I guess we could require reference semantics for all input ranges
(including forward ranges and higher-ups). That would be a rather
clean way out of this mess. But it would be a major effort. And I
guess it would hurt performance, maybe a lot.
[...]
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]));
That would also not be possible if ByRecord had an `@disable
this(this);`. But I'm not at all sure that this is the way to go.
It's bound to be forgotten, and there are probably places where
it's needlessly restrictive.
I was hoping to find some communication how input ranges should
be done.
I'm right there with you. This is all a bit iffy. I suspect that
this is an oversight in the design of ranges, as the
documentation of std.range doesn't say anything on the topic.
This may be too advanced for D.learn. I don't think Andrei and
Walter come down here very often. Maybe take it to the general
board.
At this point the solution in byLineCopy feels ad hoc.
I think byLineCopy solves a different problem. ByLine already has
this:
https://github.com/D-Programming-Language/phobos/blob/v2.067.0/std/stdio.d#L1592-L1598
