http://d.puremagic.com/issues/show_bug.cgi?id=7067
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #13 from [email protected] 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 solution. ** 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: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
