Fix Issue 18595 & Issue 18596: replace MindstdRand0 w/SplitMix & templatize unpredictableSeed!UIntType

[n8sh]

Slicing the elephant into smaller pieces. This PR differs from #6388 in that it omits entirely system entropy.

The PR's visible change is that one may now write unpredictableSeed!ulong and get a ulong. The PR's under-the-hood change is that instead of thread-local MinstdRand0 unpredictableSeed uses a global SplitMix.

Q: Why prefer global shared (atomic) instance to thread-locals?
A: It gives us an easy guarantee that the same ulong seed will not be produced by more than 1 thread except if unpredictableSeed!ulong is called 2^^64 times during the life of the application. The question should rather be, what advantage would thread-local storage give us here?

Q: What about cryptography?
A: This PR changes nothing about the current situation. unpredictableSeed is not in any sense unpredictable to an adversary willing to use mathematics.

Q: What about speed?
A: This shouldn't be a main consideration, but this implementation happens to be faster. The new unpredictableSeed takes about 1/3 the time with ldc2 -O and about 1/2 the time with dmd -O -inline. The story is even better if you compare the new unpredictableSeed!ulong to calling the old unpredictableSeed twice to produce a 64-bit value.

[dlang-bot]

Thanks for your pull request, @n8sh!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	18595	enhancement	std.random: add unpredictableSeedOf!UIntType for non-uint unpredictableSeed

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + phobos#6580"

[thewilsonator]

@n8sh does this need a changelog entry?

[n8sh]

@thewilsonator I'll add one.

[thewilsonator]

Thanks!

[n8sh]

Added.

[kinke]

With the LLVM optimizer, this whole function is optimized to calling Thread.getThis(), getpid() and MonoTime.currTime().ticks() (for potential side effects) and then returning an undefined value (i.e., no updateResult() calls, no final mixing) - due to the final value of result depending on its initial value, which is explicitly undefined (= void).

The intent probably was to make the bootstrap seed somewhat more random, but this doesn't work here. Would it be okay to initialize result with 0?

[kinke]

Quoting Johan:

Using an uninitialized value is UB in D. https://dlang.org/spec/declaration.html#void_init

[n8sh]

Would it be okay to initialize result with 0?

Yes.