http://d.puremagic.com/issues/show_bug.cgi?id=7067
jens.k.muel...@gmx.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jens.k.muel...@gmx.de --- Comment #10 from jens.k.muel...@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: -------