https://issues.dlang.org/show_bug.cgi?id=7067
--- Comment #21 from Martin Nowak <[email protected]> --- (In reply to Joseph Rushton Wakeling from comment #20) > 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. I don't think that sharing rng state among multiple consumers is a good idea. Of course it looks like you want random numbers and shouldn't care about the order, but often fixed seeds are used to get a reproducible pseudo-random range. When you share such a RNG as in auto rng = Random(fixedSeed); assert(!equal(randomCover(a, rng), randomCover(a, rng))); the sequences depends on the implementation of equal and randomCover. Would be cleaner to use 2 RNGs with independent state here, so the fact that a shared state requires to be explicit is a good thing. Also we'd set a bad precedent by making one of std's ranges a ref type. Ref ranges have a lot of subtleties and aren't that well tested with std.algorithm. --
