Denis Koroskin wrote:
Sergey Gromov Wrote: [snip]
OTOH, I'd expect something like the following to also work:
auto f = new File("blah.txt"); auto top = take(10, f.lines);
Same here. I feel that take (and some other adaptors) should accept
range by reference. One of the advantages of ranges over opApply is
that you can start foreach, break somewhere (throw an exception,
recover) and then continue. It also means that the range is mutated
inside foreach. If foreach mutates the range, so can other algorithms
that operate on ranges do.
While I'm not 100% clear on what take should do, this particular
argument is not that compelling. I really mean not compelling at all.
Consider:
int[] a = [ 1, 2, 3, 4, 5];
foreach (e; a)
{
if (e == 3) break;
}
assert(a == [4, 5]);
Do you seriously expect that to be the case? Of course not. However, you
would inconsistently expect this to happen:
int[] a = [ 1, 2, 3, 4, 5];
foreach (e; take(4, a))
{
if (e == 3) break;
}
assert(a == [4, 5]);
Ranges are modeled to correspond to slices. Slices have few operations
that manipulate them by reference (notably the controversial ~=) and
range are made to be unsurprising when compared to slices. They are
really extensions of slices.
Andrei
