How is chunkBy supposed to behave on copy

[H. S. Teoh]

On Thu, Mar 19, 2020 at 10:46:39AM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> On 3/19/20 10:28 AM, Dukc wrote:
> > On Thursday, 19 March 2020 at 14:11:20 UTC, Steven Schveighoffer wrote:
> > > 
> > > If you want to copy a forward range use save. Anything else is
> > > possible to break in an implementation detail later.
> > > 
> > 
> > Ouch - my code has to be totally broken. And I don't think I'm the
> > only one.
> 
> You are not the only one. Almost all range functions are tested with
> and use arrays, which do exactly the same for .save or copying. The
> reason why `save` is such a bad solution is because there is generally
> no penalty for ignoring it (until there is).

Yeah, Andrei has said that in retrospect, .save was a design mistake, he
should have made the input range vs. forward range distinction keyed on
copyability or ref/non-ref instead.  But to be fair, back in the day
when the range API was first designed, D didn't have the necessary
language facilities to be able to handle a better solution, unlike now
when we have @disable, copy ctors, and a bunch of other language
features that make such a solution more feasible.


> 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.
[...]

It will happen if std.v2 happens... ;-)


T

-- 
"How are you doing?" "Doing what?"