What    |Removed                     |Added
                 CC|                            |

--- Comment #13 from 2012-09-27 13:51:58 PDT ---
(In reply to comment #12)
> (In reply to comment #10)
> > then
> > std.random should be deprecated and std.random2 should replace it in the 
> > long
> > run. I believe this is the best solution (but far from perfect) to handle
> > design problems like this.
> std.random2 seems a good solution.

As I've mentioned, I am almost ready with a non-breaking reference semantic
fix. To avoid breaking code, the ranges are basically lazilly initialized.

As I've stated in the forums, I do not want to add ANY new functionality in
random, which would have to be ditched for a migration to random2 anyways. My
two ideas were:
* Explicit opSlice that returns an agressivilly initialized PRNG, for higher
performance. They'd also have tighter safety.
* A PRNG.Payload alias for users that *really* want stack allocation.

Out of curiosity, if you had to write random2, what would you want in random2?
* I'd remove all constructors, and require an explicit call to either a seed
function, or a free Make!PRNG fuction. I don't think classes is quite the right
** This would address both the explicit initialization issue, as well as the
"no-arg" initialization issue
* I'd also make them "only" input ranges. It doesn't make much sense to save a
prng (though I'd still have .dup), but they wouldn't be forwardRanges.

Not much else actually.

I was planning on asking community feedback on potential evolutions when my
developement was ready to go through (either evolving std.random, or forking to
std.random2), but I wouldn't mind a pre-release opinion from users who have
more hindsight of the issue ;)

PS: Related, I'd want std.container to require the exact same initialization
scheme >:(

PPS: No spellchecker here, sorry.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to