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