Closed DE0CH closed 1 year ago
What would be the use case for this? I enjoy being able to use an RNG
from a shared reference
I was thinking of racing condition in concurrent thread, but the Cell
prevents you from sharing an rng between threads. Now I can't think of any case where refactoring this would be beneficial. Perhaps there are some edge cases where only one mutable borrow rule can detect some bugs but I can't think of any. One minor usefulness is that it makes it clear to the user that calling .u64(..)
twice will not give you the same result.
A case where removing the interior mutability would be beneficial is when it is intended to share a Rng
across threads, e.g. #26, that is, when someone wants to use a different interior-mutability abstraction, which is e.g. thread safe, or uses atomics instead.
The use case in #26 is pretty tempting, now that I think about it. I could implement this (it would also let this crate by no_std
).
I am thinking if we can remove the internal mutability in
Rng(Cell<u64>)
by just usingRng<u64>
and implementing methods withfn ...(&mut self)
. This behaviour is more consistent with therand
crate and it also makes more logical sense because an rng mutates as you use it.This change will definitely need a major version bump.