1st draft of complete class-based std.random successor

[Rikki Cattermole]

On Thursday, 20 March 2014 at 00:15:22 UTC, Joseph Rushton 
Wakeling wrote:
> On Thursday, 20 March 2014 at 00:05:20 UTC, Joseph Rushton 
> Wakeling wrote:
>> Not really.  There's still usable functionality in there for 
>> all architectures (although I'm not sure how practically 
>> useful).
>
> Just to expand on that remark: my impression is that individual 
> random devices are inevitably going to be 
> architecture-dependent.
>  /dev/random and /dev/urandom are Posix devices; Windows AFAIK 
> has its own alternative.  So the broad idea is that you'd have 
> as much generic functionality as possible available to all 
> architectures (mostly related to what sources you read from; a 
> file, a socket, something else?), and then individual 
> architecture-dependent aliases would map this to particular 
> random sources available to them.
>
> Then, finally, you'd have some default alias RandomDevice that 
> would point to an appropriate architectural default; so e.g.
>
>     version (Posix)
>     {
>         alias RandomDevice = DevURandom!uint;
>     }
>     else version (Windows)
>     {
>         alias RandomDevice = ...
>     }
>     // etc.
>
> ... so, unless you were quite specific about your requirements, 
> 90% of the time you could just use RandomDevice and expect it 
> to Just Work whatever your platform.
>
> But as random devices are not my strongest area of expertise, 
> I'll happily take advice here.

For version blocks of code, I try to make sure they implement the 
same interfaces like this one. To limit the possible issues.
It just makes things a little more cleaner for API users.

In the case that this isn't production ready the static assert 
can be used as a TODO type of thing. Forcibly telling you it 
isn't done yet. Its better than silently going into production 
and finding out that a main platform isn't ready.

But this is just my preference.