https://issues.dlang.org/show_bug.cgi?id=7067
--- Comment #20 from Joseph Rushton Wakeling <[email protected]> --- (In reply to Martin Nowak from comment #19) > We had a talk about this during the 2nd D meetup in Berlin. > One remaining question was how to deal with memory management when using a > reference type RNG. > > I came up with a different solution and less invasive solution. > > We simply disable implicit copying of RNGs (@disable this(this)) and ask > people to use explicitly use .save when copying is indeed intended. > > We can even deprecate postblit like so. > > deprecated("Please use .save to explicitly copy RNGs.") > this(this) {} > > Internally we'd need to change all copying to use std.algorithm.move. Interesting thought. We'd have to take care that phobos-side things don't get immediately "fixed" by people just using .save inside RandomCover and RandomSample constructors. > If reference semantic is wanted people can use either > new Random(unpredictableSeed) > or > refCounted(rnd) > refCounted(Random(unpredictableSeed)) > or (unsafe) > refRange(&rnd) > . > > This should also work for combined random generators like. > > new Exponential(Random(unpredictableSeed)) > > refCounted(Exponential(Random(unpredictableSeed))) > > auto rng = Exponential(Random(unpredictableSeed)); > refRange(&rng); I guess what I don't like about this solution is that it requires the user to take responsibility for generating the RNG (or wrapper-of-RNG) as a reference type, when that ought to be the default behaviour. But OTOH we could take advantage of the fact that RNG structs are templated, and rework their convenience aliases, e.g.: alias Mt19937 = RefCounted!(MersenneTwisterEngine!(uint, 32LU, 624LU, 397LU, 31LU, 2567483615u, 11LU, 7LU, 2636928640u, 15LU, 4022730752u, 18LU)) ... which would still leave the underlying struct available for use by someone who really wants to use it directly in that form. --
