Yes, but the example I gave does just that, with a catch-all method. The problem is that you will get ambiguities in some cases, it would be great to figure a way to have less of those in Random
.
In the example I gave yes, at least when wrapping MersenneTwister
(and most likely for all currently existing generators, unless they specialize generation of UInt52
). You can’t predict how a function will use an RNG. In the case of randn
, only by looking at the source code can you see that it uses rand(UInt52())
and decide to count that the same as if it was generating a Float64
. Another routine could generate an Int
and treat it as a Float64
. Ultimately, an RNG
just produces random bits which are put together into a value of a certain type. Another way to solve the problem is to count the number of generated bits, at the lower level of the generator. But then you don’t discriminate between e.g. integers and floats.