hap.random: a new random number library for D

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 20 June 2014 at 18:15:49 UTC, Nick Sabalausky wrote:
> I'm on the fence:
>
> Pro: Upgrade paths and backwards compatibility are great, 
> especially for Phobos.
>
> Con: If any semantics are changed (default ref/value passing is 
> the only one that comes to mind), then maybe it would mask 
> potential upgrade issues. Breakage would force users to notice 
> the change and (hopefully) deal with it appropriately.
>
> I don't personally see it as a big deal either way, though.

Sorry for taking so long to follow up on this, it's been a busy 
period ...

Anyway, here's my thinking behind the opCall idea.  One of the 
major shifts of the move to classes is that, suddenly, all of 
these entities have to be explicitly allocated.  That means that 
there's some measure of responsibility on the library to offer a 
sane default style of allocation, as appropriate for the expected 
use-cases and performance requirements.

Now, apart from the random number generators, all of the 
remaining library functionality already has helper functions 
which can handle this.  Currently they just "new" stuff, but 
there's no reason this can't be adapted as needed, possibly with 
the option for some kind of templating around different 
allocation strategies.

However, RNGs themselves don't have any corresponding helper 
functions, and manually writing them out would fast become 
annoying (imagine having to create, say, xorshift, xorshift32, 
xorshift64, ... etc. as helper functions to create Xorshift, 
Xorshift32, Xorshift64, etc., instances).

opCall provides a natural way of implementing such construction 
helper functions that is likely very general purpose, and 
encouraging it as the default use-case has a further benefit of 
encouraging the user to always seed their RNGs, if opCall has a 
form like this:

     static typeof(this) opCall(Seed)(Seed seed)
     {
         return new typeof(this)(seed);
     }

It _could_ be done as a temporary measure, deprecated from the 
start, to allow drop-in replacement but encourage appropriate 
adaptation.  But it could also be a way to serve the user with 
sensible default allocation strategies that minimize the 
potential performance impacts of the switch to classes.