Mir Random [WIP]

[Joseph Rushton Wakeling via Digitalmars-d]

On Wednesday, 23 November 2016 at 05:58:47 UTC, Ilya Yaroshenko 
wrote:
> It is safe low level architecture without performance and API 
> issues. It prevents users to do stupid things implicitly (like 
> copying RNGs). A hight level range interface can be added in 
> the future (it will hold a _pointer_ to an RNG).

Note that if you want to do this, it's convenient to still 
preserve a separation between popping the RNG state versus 
getting the current variate.  Otherwise, the range interface will 
wind up having to separately cache the variate value, which is 
wasteful.

Something like this:

struct MyRNG
{
     void popFront() { /* update internal state */ }

     UIntType front() @property { return /* whatever part of 
internal state */; }

     UIntType opCall()
     {
         this.popFront();
         return this.front;
     }
}

(The above is basically just the input range API less the `empty` 
property, and the `front` and `popFront()` are arguably a 
lower-level API than `opCall`.)

> In additional, when you need to write algorithms or 
> distributions opCall is much more convenient than range API.

Can you give some examples of what you mean here?

>  In additions, users would not use Engine API in 99% cases: 
> they will just want to call `rand` or `uniform`, or other 
> distribution.

I don't think that's necessarily true, but in any case, we 
shouldn't restrict the use-cases of the 1% unless we have to.