Karl
November 6, 2021, 1:01am
2
Also, credit to @benrimmington and @Nevin for pointing this out during the review 3 years ago. From what I can see, the point was accepted but not acted on. I think we would reconsider it.
Should a next(_ bytes: UnsafeMutableRawBufferPointer) method be added to the protocol? This could be in addition to, or instead of, the generic next<T: FixedWidthInteger & UnsignedInteger>() -> T method. It could even replace the next() -> UInt64 method, but in that case other generators might need to use an internal buffer.
It works, but if using the default generator, _stdlib_random would be called repeatedly, instead of only once.
Perhaps more importantly, we could include a requirement akin to arc4random_buf() , which takes an inout MutableRawBufferPointer and fills it with random bits. Depending on the algorithm, this could potentially bring a significant speedup.
3 Likes