Fixing implicit copies of InputRanges [was: Re: Mir Random [WIP]]

[Jonathan M Davis via Digitalmars-d]

On Saturday, November 26, 2016 12:24:47 Andrei Alexandrescu via Digitalmars-
d wrote:
> On 11/26/2016 01:55 AM, Martin Nowak wrote:
> > On Saturday, 26 November 2016 at 06:46:19 UTC, Martin Nowak wrote:
> >> Maybe non-copyability needs to become a requirement for InputRanges.
> >
> > Could have an optional .clone if copying is supported.
> > What would be an InputRange where copying is correct?
>
> Input ranges with disabled this(this) would be a major breaking change
> that we probably cannot bear (and shouldn't because the gain is small).
> I think an input range would be at best "pure reference" in the sense
> that popFront advances all copies to the same position. -- Andrei

For a while now, I've been tempted to argue that we should require that
well-behaved input ranges be reference types (or at least have reference
semantics). It just seems like too much misbehaves if they're not, and
arguably, the whole reason that they're input ranges and not forward ranges
(aside from the programmer just not bothering to implement save) is that
they effectively have reference semantics whether they're actually coded
that way or not. We obviously can't test for that behavior at compile time,
but it could easily be on the list of things that are documented as a
requirement for well-behaved ranges.

I'm also tempted to argue that well-behaved forward ranges and greater
should have value semantics (in the sense that dynamic arrays do), but
that's a much bigger change (it effectively makes save unnecessary), and
proper use of save works around that problem (though it's very common that
save isn't used as often as it should be). It would clean up a lot of the
mistakes that occur with forward ranges though.

However, regardless, a non-copyable range would not play nicely at all with
how range-based code works right now. You'd have to use ref all over the
place, which range-based code simply doesn't do and would not play well with
function chaining, since you'd need lvalues, and since you couldn't copy the
range to the stack to make it an lvalue, that seems like it would go nowhere
fast.

- Jonathan M Davis