On 06/18/2013 08:35 PM, Jonathan M Davis wrote: > Regardless, I think that we should be sure of what we want to do with the > module as a whole before we start making tweaks like that, since if we decide > that we really do want std.random2, there's not much point in tweaking > std.random, and std.random2.rndGen could return what we want. If we do stick > with std.random though, I think that we should come up with a better name > than > rndGenRef (maybe rndRange or genRnd or simply random).
If you're having a std.random2 then I don't see a reason to change the name -- keep it as rndGen. In _most_ cases of downstream code it won't break, so it smooths the upgrade path. I presume using std.random and std.random2 together would be considered an error, so is there really any risk of a clash? Also, assuming we do go with std.random2 rather than an upgrade to std.random, it may be better to go with structs-carrying-a-pointer-to-a-payload rather than with classes; that in turn might allow for less breakage in users' code. For example, if the Random alias is switched from a struct to a class, then users would have to go through their code tweaking stuff like this: - auto gen = Random(unpredictableSeed); + auto gen = new Random(unpredictableSeed); Whereas if RNGs are still structs on the outside (with reference to payload inside) then the original line should still work.