[Issue 7067] std.random.RandomSample and RandomCover are poorly designed

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Sep 27 13:51:25 PDT 2012


http://d.puremagic.com/issues/show_bug.cgi?id=7067


monarchdodra at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra at gmail.com


--- Comment #13 from monarchdodra at gmail.com 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: -------


More information about the Digitalmars-d-bugs mailing list