Should RNGs really be clone?

[brson]

We recently made most, but not all RNGs clonable. ISTM that the use cases for this are quite limited, and it creates a big opportunity for making mistakes by duplicating random numbers in scenarios where that could be a security risk (imagine accidentally deriving clone on a secure rng).

cc @aturon

[nagisa]

Relevant discussion wrt Copy: http://discuss.rust-lang.org/t/copy-impl-for-random-number-generators/1218

[huonw]

Hm, secure by design is attractive, but this may be pushing further than necessary with little gain. Completely disallowing the copying of RNGs (the same argument implies removing Copy, which we should probably do since that trait is even worse) sounds unfortunate since that completely removes actual functionality; I could imagine a game/simulation wanting to save state to be able to rewind/reproduce.

Also, C++11's random library supports copying, e.g.:

#include<random>
#include<iostream>

int main() {
    std::default_random_engine r(0);
    std::default_random_engine r2(r);

    std::cout << r() << " " << r2() << std::endl; // 16807 16807
}

(Of course, C++ isn't necessarily the best example.)

I'm... in two minds.

[Gankra]

It seems reasonable to be able to fork RNGs via clone to replay behaviour.

[sfackler]

One option that may or may not be a good idea is to expose a clone-like method but not actually implement Clone.

[nagisa]

For all its worth, cloning for replays doesn’t work for ThreadRng (which implements Clone only because it is possible) since it will get reseeded at some point.

[Gankra]

Hmm... we need to decide on this before 1.0, right?

[nagisa]

Yes. Neither Copy, nor Clone can be removed after 1.0 back-compatibly.

[aturon]

@gankro the plan is for @huonw to do stabilization -- I believe he's writing an RFC on the topic. I assume this issue will be addressed there.

[aturon]

Closing: std::rand has been deprecated and will soon be removed.