On 64-bit architectures use 64 bits of entropy to initialize
thread-local `rndGen`.
The motivation for this change is std.uuid defaults to using `rndGen`
to generate UUIDs. If every `rndGen` starts in one of 2^^32 states then
if 77000 independent programs each generate a single UUID there is a 50%
chance that at least two of them generate the same initial UUID (and all
subsequent UUIDs would be identical as well). Not just Phobos but also
C++ boost::uuids::random_generator defaults to generating UUIDs with a
Mersenne Twister initialized from a 32-bit seed, exacerbating the
collision problem further. If instead there are 2^^64 possible initial
states of `rndGen` there can be over 5 billion independent `rndGen`s
before there is a 50% chance of two having identical initial states.
This change is limited to 64-bit architectures to avoid a measurable
performance decrease, because many programs are not generating UUIDs.
Fix Issue 18327 - std.random.XorshiftEngine is parameterized by UIntType but only works with uint
merged-on-behalf-of: Nicholas Wilson <thewilsonator@users.noreply.github.com>
This passes all Phobos tests and would be really nice for no-exceptions situations, instead of appending `assumeWontThrow` to everything. Should be quick.
Also:
* Add ability to specify shift directions.
* Allow arbitrary XorshiftEngine sizes instead of predefined list only.
* Except when array is small, use index to make speed of `popFront`
independent of array size.
Fix Issue 19156 - `@nogc` std.random.randomShuffle
Solution is to use a private `_randomIndex` function that is guaranteed
to be called only with valid bounds.
Issue 18715 - Non-documented unittests should not use unpredictableSeed or default Random alias
merged-on-behalf-of: Nathan Sashihara <n8sh@users.noreply.github.com>
The fix for 18631 broke code. Ranges cannot be marked with const or
inout in generic code. The range API does not require that any functions
be const or inout. In this case, with the changes, choice requires that
length and opSlice be const, breaking any code that uses a range with
choice that does not have a const length or opSlice (which is going to
be a large percentage of ranges with those functions which aren't
arrays).
XorshiftEngine.min is defined as 0 regardless of template parameters
but an XorshiftEngine cannot produce a value of zero if its internal
state has the same number of bits as the output element type.
Random choice default argument was deciding the type of the
template. I'm not sure if this is a deeper bug, but it can easily be
fixed with this patch which simply overloads the function.
Also added a unittest which would have failed under the old code.
