A few weeks ago I suggested removing Copy trait derivation from random number generators that currently implement it.
This is my motivation from now-closed PR:
Copying is an implicit operation and the copy shares its internal state with the original generator. This means the the two generators will yield exactly the same sequence of values. This behaviour is considerably easy to trigger by, for example, passing the generator by value to a function. Clone trait, on the other hand, does no implicit copying. The user will only be able to either move the generator or ask for a copy explicitly, via the clone method. The only downside to this patch is the fact that the implementations of Clone::clone methods do not optimise down to a single memcpy, like the derived Copy implementations did.
The PR received some conflicting feedback from some core team members. Summary:
Copyis used as a bound on some functions/structs and has useful properties;
Copyas a bound is only used in a few APIs in Rust standard library;
Copyimplementation can always be added later, but not removed.
Clone implementation has already been merged for most RNGs (#20483), and the fate of
Copy needs to be decided. Should the
Copy implementation for ChaChaRng, Isaac64Rng, IsaacRng and StdRng be removed?
cc @aturon as per his request.