On Thursday, 24 November 2016 at 14:22:05 UTC, Jonathan M Davis wrote:
> Then call popFront or drop before passing it along if you're paranoid about it.

There's little need for it, as it was pointed out earlier that the generate algorithm does the right thing and needs only opCall, also a nice example of orthogonality and composability.

On Wednesday, 23 November 2016 at 01:34:23 UTC, Andrei Alexandrescu wrote:
> On 11/22/16 7:30 PM, John Colvin wrote:
>> On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei Alexandrescu wrote:
> The proposed design has disabled copy ctor and uses opCall() for a new element. That seems to be a difference without a distinction from an input range that has disabled copy ctor and offers the input range primitives.

Yes the problems are inadvertent copies and a disabled this(this) would prevent that. RNGs should have unique ownership of their internal state.
Using InputRanges with phobos is somewhat clumsy. Maybe people have been burned by those and now generally consider InputRanges as broken.
Maybe non-copyability needs to become a requirement for InputRanges.

> We should add a reference RNG that transforms any other RNG into an input range that shares the actual RNG.

We already have refRange for that, no?
Also refCounted(Random(unpredictableSeed)) should work.

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?

> We already have refRange for that, no?
> Also refCounted(Random(unpredictableSeed)) should work.

Same scheme works for files with only plain int fds streams, non-copyable/unique ownership, and move, refRange, or refCounted for passing and sharing.

Should we split off this discussion to a dlang-study thread?

On Saturday, 26 November 2016 at 06:46:19 UTC, Martin Nowak wrote:
> Yes the problems are inadvertent copies and a disabled this(this) would prevent that. RNGs should have unique ownership of their internal state.
> Using InputRanges with phobos is somewhat clumsy. Maybe people have been burned by those and now generally consider InputRanges as broken.
> Maybe non-copyability needs to become a requirement for InputRanges.

I remember you made that suggestion of disabled this(this) to me a while back, and I did use it for this small collection of RNGs:
https://github.com/WebDrake/dxorshift

>> We should add a reference RNG that transforms any other RNG into an input range that shares the actual RNG.
>
> We already have refRange for that, no?
> Also refCounted(Random(unpredictableSeed)) should work.

RefRange still has the issue that it only forwards the range primitives and not other properties such as the `isUniformRandom` enum.  But those are probably fixable.

However, these approaches basically cover the case of something where an instance is initialized high up in the program and passed around by ref throughout its lifetime.  That doesn't address the question of how random _algorithms_ like `RandomSample` could be updated for safety (since they might often need to be initialized multiple times in the inner loops of a program).  See:
https://forum.dlang.org/post/gnlvyogolkmocujtnxjj@forum.dlang.org
https://forum.dlang.org/post/gpsilefdillwtleuwohl@forum.dlang.org

for some discussion of the problem.

On Saturday, 26 November 2016 at 06:55:24 UTC, Martin Nowak wrote:
> Should we split off this discussion to a dlang-study thread?

I would personally really welcome that, but subject to the understanding that people agree to look seriously at random algorithms (like RandomSample) and not focus the discussion solely on RNGs.

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

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