Input ranges
anonymous via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Sun Apr 19 16:49:07 PDT 2015
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
More information about the Digitalmars-d-learn
mailing list