isUniformRNG

[Joseph Rushton Wakeling via Digitalmars-d]

Hi Nick,

Short reply because I think things are converging pretty well decision-wise :-)

>> because crypto RNGs' .popFront() is of necessity going to be non-pure.)
>>
>
> To make sure I understand (it seems my understanding of D's pure isn't quite as
> strong as I'd thought): It cannot be pure *because* of the static internal
> state, right?

The main issue is because your popFront will be relying on external sources of 
entropy which I presume to be non-deterministic (otherwise, what entropy are 
they adding?).  That's what makes purity impossible.

As we've discussed, you could avoid having the static variables, but as the 
function is going to be impure anyway, they shouldn't be avoided over the purity 
issue.

>> If the DConf discussion related to an experimental part of the standard
>> library are anything to go by, I think we will have plenty of
>> opportunity to implement functionality that is subject to change, so I
>> don't think we need fear doing that.
>
> I think I may have missed that particular discussion (I've only been catching
> the livestreams of certain talks). Recap?

Andrei's opening keynote seemed pretty clear that we need a space in the 
standard library where people can experiment freely.  He called it 
std.experimental but I suspect the name will be something different :-)

> If truly "no need to fear adding functionality that's subject to change", then
> that also answers another question I was about to raise: Submit a PR for this
> algorithm now, or just simply incorporate it as part of your new std.random yet
> to go through the approval process? May as well go with "now".
>
> This is one last matter: Should my initial PR for Hash_DRBG be struct-based or
> class-based? While we both agree that class-based is a better approach overall,
> the current std.random is still struct-based and your class-based version hasn't
> gone through the approvals process yet (I assume it needs to, since it's a
> fairly big reworking of a whole phobos module).

Well, what I'm inclined to do is to submit my Phobos package as an experimental 
module (probably call it exp.random or something like that).  I can and probably 
will do that in the very near future.

I think that you should similarly feel unrestricted, but maybe give it a day or 
two post-Dconf to see what the actual plan is about the experimental repo.

By the way, what are your thoughts on having a std.random.crypto module versus a 
general std.crypto module that includes crypto RNGs and other crypto 
functionality?  I'd been considering a std.random.crypto but I'm starting to 
incline towards the view that std.random and crypto should be kept deliberately 
separate.

Best wishes,

     -- Joe