On 02/08/15 03:38, Dicebot via Digitalmars-d-learn wrote:
> On Saturday, 1 August 2015 at 17:50:28 UTC, John Colvin wrote:
>> I'm not sure how good an idea it is to totally enforce a range to be
>> non-copyable, even if you could deal with the function call chain problem.
>> Even in totally save-aware code, there can still be valid assignment of a
>> range type. I'm pretty sure a lot of phobos ranges/algorithms would be unusable.
>
> This is exactly why I proposed to Joe design with destructive copy originally -
> that would work with any algorithms expecting implicit pass by value but prevent
> from actual double usage.
>
> Sadly, this does not seem to be implementable in D in any reasonable way.

Yup.  This work is follow-up on a really creative bunch of suggestions Dicebot made to me on our flight back from DConf, and which we followed up on at the recent Berlin meetup.

The design principle of "destructive copy" is great -- it really cuts through a bunch of potential nastinesses around random number generation -- but it really doesn't look like it's straightforwardly possible :-(

On Saturday, 1 August 2015 at 11:47:29 UTC, Joseph Rushton Wakeling wrote:
> Yea, but that's not what I'm trying to achieve.  I know how I can pass something to `take` so as to e.g. obtain reference semantics or whatever; what I'm trying to achieve is a range that _doesn't rely on the user knowing the right way to handle it_.

Wrapping a reference to a stack-allocated struct is also unsafe, so no way for the user to not know about it.

On Saturday, 1 August 2015 at 12:10:43 UTC, Joseph Rushton Wakeling wrote:
> On the other hand, what you want to disallow is this:
>
>    auto sample = iota(100).randomSample(10, gen);
>
>    sample.take(5).writeln;
>    sample.take(5).writeln;   // statistical correlations result,
>                              // probably unwanted

Try
auto sample = iota(100).randomSample(10, &gen);

On Monday, 3 August 2015 at 08:54:32 UTC, Kagamin wrote:
> On Saturday, 1 August 2015 at 11:47:29 UTC, Joseph Rushton Wakeling wrote:
>> Yea, but that's not what I'm trying to achieve.  I know how I can pass something to `take` so as to e.g. obtain reference semantics or whatever; what I'm trying to achieve is a range that _doesn't rely on the user knowing the right way to handle it_.
>
> Wrapping a reference to a stack-allocated struct is also unsafe, so no way for the user to not know about it.

It is now verified as safe by `return ref`.

On Monday, 3 August 2015 at 09:01:51 UTC, Dicebot wrote:
> It is now verified as safe by `return ref`.

Yes, until you pointed this out to me I'd been convinced that classes were the way forward for RNGs.  I think that `return ref` is going to be a _very_ powerful tool for facilitating stack-allocated RNG functionality.