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

[d-bugmail at puremagic.com]

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


jens.k.mueller at gmx.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jens.k.mueller at gmx.de


--- Comment #10 from jens.k.mueller at gmx.de 2012-06-19 07:30:43 PDT ---
(In reply to comment #2)
> (In reply to comment #0)
> > The following tests will always fail:
> > 
> >     int[] a = [ 0, 1, 2, 3, 4, 5, 6, 7, 8 ];
> >     assert(!equal(randomCover(a, rndGen()), randomCover(a, rndGen())));
> >     assert(!equal(randomSample(a, 5, rndGen()), randomSample(a, 5, rndGen())));
> 
> Good point.
> 
> > The reason why these tests will fail is that both functions take the RNG by
> > value.
> >
> > Not only is this unintuitive, this is also a security liability -
> > someone depending on these functions to generate random identifiers can be
> > surprised that two successive calls generate the same ID.
> 
> I think we can safely eliminate this argument from the discussion.
> 
> > I strongly suggest that RNG types are disallowed from being implicitly copied.
> > Even though pseudo-random number generators shouldn't be used for security
> > purposes, they're still likely to be used in such contexts - especially
> > considering lack of better sources of random data in Phobos.
> 
> The problem with taking a random generator by reference is that it then needs
> to be escaped. So people would be quite surprised to see that:
> 
> auto gen = rndGen;
> return randomSample(a, 5, gen);
> 
> has undefined behavior.

Code like this is always incorrect, i.e. the problem is more general. I wonder
whether a compiler can always flag those programs as invalid. Is it possible to
solve the problem of escaping references to local variables in general?
If so it should probably be done that way. And a RNG should be made
non-copyable to force pass by ref.
If it isn't possible (or inefficient or too time consuming, etc.), 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. I wish there was a better way to fix a wrong design
decision. But working around (kind of against the language) is not
future-proof.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------