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
