How is chunkBy supposed to behave on copy

[H. S. Teoh]

On Thu, Mar 19, 2020 at 03:35:28PM +0000, Dukc via Digitalmars-d wrote:
> On Thursday, 19 March 2020 at 14:46:39 UTC, Steven Schveighoffer wrote:
> > The only way to "fix" this IMO is to migrate to a system where
> > standard (non-forward) input ranges are not copyable, and deprecate
> > save. It likely will never happen.
[...]
> Perhaps there is another way. Individual ranges can give guarantees
> about their own copy behaviour if they want. We could document the
> current copy behaviour of existing Phobos ranges and say that relying
> on it is thereafter fine.

The problem is, you *cannot* give any guarantees about copy behaviour,
because it depends on the behaviour of the incoming range. For example,
if you pass the output of .byChunk to another range algorithm, that
second algorithm cannot guarantee copy behaviour anymore.

In fact, all you have to do is to wrap a forward range in an
InputRangeObject (let's say you need to alternate between two different
range types (but with compatible elements) at runtime, then you'll need
to do this), and now you have a forward range with by-reference
semantics that requires the use of .save in order to retain its current
position.

This is (likely) part of the reason why the range API does not specify
the behaviour of a range once it's iterated over without using .save: it
depends on implementation details.


> But then the question with `chunkBy` is, should it take the
> opportunity to start to behave like most other ranges in this regard?

I don't see why this should be a compelling reason to change chunkBy --
since copy behaviour is not specified by the range API (for IMO good
reasons -- it's implementation-specific).  But I do agree that the
implementation of chunkBy could be improved for other reasons, like not
using the expensive ref-counting implementation when the underlying
range is, say, a native array that you could just slice over.


T

-- 
MAS = Mana Ada Sistem?