This is not a valid conformance to RandomNumberGenerator, because it does not produce a uniform random value in 0...UInt64.max. This is pretty clear if we print a few values in hex in the REPL:

Because this is not a valid conformance, algorithms that transform its output do not behave as expected. In particular, because the value produced by next() is always less than 0x40..., generating random integers with an upper bound of 4 will always produce zero.

If you really want to build a conforming RNG out of drand48() specifically, you can do that as follows:

(Why 0x1.0p64 and 0x1.0p16? Because drand48() produces 48 bits scaled to fit in (0,1); multiplying by 2⁶⁴ before conversion gives us a random value filling the high-order 48 bits of the UInt64, multiplying by 2¹⁶ fills the low-order 16 bits (and lets the next 32 bits be chopped off, since conversion to UInt64 throws away any fractional bits).