[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