hap.random: a new random number library for D

[bearophile via Digitalmars-d-announce]

Joseph Rushton Wakeling:

> What really matters to me is stuff like Sample and Cover, where 
> we can readily expect that they may be called in inner loops of 
> the program, and so having lots of allocations via "new" would 
> be a big problem.  So, it follows that the current helper 
> functions (sample, cover, etc.) need to be rewritten at some 
> point with this in mind.

I think @nogc is a good improvement for D, despite Walter and 
other people (and I think Don) were very sceptical about it, 
because it's like a new lens that allows me to see important 
things about my code that I wasn't able to see before. Phobos has 
to be modified in many places to allow both usage patterns for 
people that want to write short clean code (that allocates 
automatically and lets the GC free), and performance-conscious 
people that need to avoid most or all heap allocations. What's 
unfortunate is that the @nogc attribute was not present for lot 
of time of development of Phobos, so several Phobos things now 
need to be modified and some old APIs could give problems. 
std.random2 should offers ways to be used as much as possible 
from @nogc code, see below.


> It's not a problem I propose to solve for the 1.0.0 release, 
> but it is a problem that needs addressing in the long run.

Even if the 1.0.0 release of std.random2 is not much @nogc, in my 
opinion it needs to have an API designed to allow it to be 
retrofitted cleanly and nicely for @nogc usages too.


> do you have any ideas or suggestions for how to address the 
> requirement for RNGs and related functionality to be reference 
> types, together with the wish to support @nogc ... ?  
> Preferably in a way that avoids the user having to explicitly 
> indicate destruction?

If you are not using the GC, and you don't want to indicate 
destruction, you have to use RAII and perhaps RefCounted. You can 
allocate on the C heap manually, or on the stack, or you can 
allocate on the stack or C heap using one of Andrei's future 
allocators.

Bye,
bearophile