December 22
About package
>Mir-Random [1] is a random number generator library that covers C++ STL [2]. It is compatible with mir.ndslice, std.algorithm, and std.range. In the same time mir.random has its own API, which is more secure and safe compared with std.random.

Release 0.3.0
You may find the release notes with hyperlinks more useful:

Performance Increases
We now use Daniel Lemire's fast alternative to modulo reduction. Compiling with LDC 1.6.0 for x86-64, Mt19937_64 randIndex throughput increased 40% for uint and 136% for ulong. Xoroshiro128Plus randIndex throughput increased 73% for uint and 325% for ulong.

The required mir-algorithm version has increased to v0.7.0 because extMul is necessary for the ulong version.

New since v0.2.8
- New engine: SplitMix64 / Splittable64
- Convenience functions related to thread-local randoms: rne (like std.random rndGen); threadLocal!Engine for arbitrary engine; & ways of mucking about with the bookkeeping state that most people won't need but a few have requested in the past.
- Made some engines compatible with APIs that expect std.random-style UniformRNG. Compatible as-is: Xoroshiro128Plus; all predefined PCG engines; and the new SplitMix64/Splittable64 engines. For any others there is an adaptor. Copy-constructors are disabled so they will only work with functions that "do the right thing" and take PRNGs by reference and don't make implicit copies of them.

Fixed since v0.2.8
- Changed many parts of the library to be @safe.
- Linux GETRANDOM in unpredictableSeed now works on non-x86/x86-64 architectures.
- Removed endian-dependency when producing 64-bit values from a native-32-bit PRNG.

Changed APIs
- The versions of genRandomBlocking/genRandomNonBlocking that take a pointer and a length are no longer @trusted. Instead there are trusted overloads for both that take a ubyte[].
- mir.random.algorithm has been changed in the interest of memory safety. You can still write unsafe code but now if you try to write @safe code the library will let you. Instead of taking engines by reference and storing their addresses (which could result in the stored address outliving the engine), now the various functions require arguments to be either objects or pointers to structs. For local-scoped engines there are templates with alias parameters. This is a major API change so feedback/criticism is welcome.