How is chunkBy supposed to behave on copy

[H. S. Teoh]

On Wed, Mar 18, 2020 at 12:18:04PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
[...]
> The long answer is, rangeBy uses reference counting internally to
> store the range data. I'm not sure why this is,

Because Andrei demanded it when I submitted the PR. The main reason is
to address the issue of what happens when you iterate the outer range
while retaining a copy of an inner range. In my original implementation,
advancing the inner range also advances the outer range, and vice versa,
but only when it's an input range. When it's a forward range, it takes
advantage of .save to decouple iteration on an inner range from
iteration on the outer range.  But that meant that iterating over the
entire thing required traversing the original range twice: once in each
inner range, and once on the outer range.  Andrei didn't like this, so
we hashed out several solutions and eventually settled on the reference
counting one.


> as it seems possible to do without this mechanism. It seems there is
> some optimization surrounding pushing along the range without
> iterating it twice. But I don't know if that's a worthwhile
> optimization, especially if the allocation and reference counting are
> more expensive than the iteration.

That's up for debate, but yes, the whole point of the reference counting
thing is to avoid traversing a forward range twice when iterating over
subranges.  It really depends on what the original range does, IMO.  If
it's generating values on-the-fly with an expensive calculation, you
could be saving quite a bit of work. But for simple ranges, yeah,
reference-counting inner ranges is kinda overkill, probably with a
performance hit.


> I would think you could get away with simply storing the range twice,
> and using .save to make sure you don't have problems.
[...]

This is what the original implementation did, but Andrei did not like
it.


T

-- 
Старый друг лучше новых двух.