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

[Joseph Rushton Wakeling]

On Thursday, 20 March 2014 at 01:32:41 UTC, Chris Williams wrote:
> Any chance that you could describe them? I was about to resume 
> porting the dcrypt library into Phobos, and had intended to 
> flip the classes into structs, to match what the rest of the 
> library was doing.

I think there's a good case for a std.random2.crypto module that 
contains RNGs that are specifically suitable for cryptography.  
That said I think the bar here has to be set VERY high, which is 
why I didn't even begin working on it yet.  It has been argued by 
some that where crypto in Phobos is concerned, we shouldn't take 
community contributions but we should hire security experts to 
write the functionality for us.

Anyway, let's keep in touch about this and discuss how we could 
support one another's efforts.

About the issues with value-type RNGs (as monarch_dodra says, 
it's not structs vs. classes per se, as you can implement 
reference types via structs; it's just more finnicky to do so), 
probably the best starting point is to read through the various 
bugs that have been reported as a result of this:
https://d.puremagic.com/issues/show_bug.cgi?id=7067
https://d.puremagic.com/issues/show_bug.cgi?id=7936
https://d.puremagic.com/issues/show_bug.cgi?id=8247
https://d.puremagic.com/issues/show_bug.cgi?id=10322

Although some of these are marked as fixed, the fixes are pretty 
unpleasant and are workarounds rather than solutions of the 
underlying problem.  It may look like only a few issues, but the 
implications are nasty.  We had extensive discussions about this 
over the last year:
http://forum.dlang.org/thread/mailman.259.1357667544.22503.digitalmars-d@puremagic.com
http://forum.dlang.org/thread/mailman.1017.1370879340.13711.digitalmars-d@puremagic.com
http://forum.dlang.org/thread/mailman.1157.1371497540.13711.digitalmars-d@puremagic.com
http://forum.dlang.org/thread/mailman.1209.1371565034.13711.digitalmars-d@puremagic.com
http://forum.dlang.org/thread/mailman.443.1377369357.1719.digitalmars-d@puremagic.com
http://forum.dlang.org/thread/5218FD04.8040404@webdrake.net

The bottom line is that implementing your RNGs as classes 
automatically gets you out of the worst of these traps by giving 
you reference semantics from the get-go.  Whether there are other 
problems that arise from this that make you prefer another design 
is a question you'll have to answer for yourself -- someone may 
yet come up with an objection that shows my current design is a 
Very Bad Idea ;-)

Anyway, the example with rndGen.take(10).writeln that 
monarch_dodra gave is probably the best argument one can make.  
Imagine a cryptographic application where you're generating 
(supposedly) two different sets of random data, and because of an 
unintended value-type copy like this they turn out to be 
identical.  Insecure much? :-)