Internally, I know that Swift has a Linux shim for arc4random. However, it's unlikely that any modern random number generator facility in Swift would rely on arc4random in such a way.
This topic has been broached on Swift Evolution previously. It's interesting to me that Steve Canon is so certain that CSPRNGs are the way to go. I wasn't aware that hardware CSPRNGs have come such a long way and are so ubiquitous as to be feasible as a basis for Swift random numbers. If so, great. Otherwise, if there is any way that a software, non-cryptographically secure PRNG is going to outperform a CSPRNG, then I think it's worthwhile to have a (carefully documented) choice between the two. I would imagine that for many uses, such as an animation in which you need a plausible source of noise to render a flame, whether that is cryptographically secure or not is absolutely irrelevant but performance may be key. I have implemented Xorshift128+ and Xoroshiro128+ in a Swift numerics library here: https://github.com/xwu/NumericAnnex/tree/master/Sources They are, of course, *non*-cryptographically secure random number generator algorithms, but these implementations rely on the hardware for a cryptographically secure seed. A (useless) vignette for how my classes would be used is: ``` let random = Random()! // Initializing a `Random` from a cryptographically secure random seed may fail, // since it is possible that the system may not have enough entropy. Better to be // transparent about this than to proceed with some sort of less-than-secure // alternative source of entropy. let x = random.uniform() as Int // You can also pass the desired result type as an argument. let y = random.uniform(Int.self) if x > y { print("Here's a random value between 0 and 42 (inclusive):") print(random.uniform(a: 0, b: 42)) } else { print("Here's a random value between -42 and 0 (inclusive):") print(random.uniform(a: -42, b: 0)) } ``` If you look through the design of the `PRNG` protocol, you'll see how easy it is to implement functions that return a sequence of random values, in some desired distribution. The overall design is inspired by the C++ STL random number generator APIs, as well as some very cogent commentary on how the C++ STL random number generator APIs are unnecessarily complicated. No matter how far we simplify, though, I agree with commentators elsewhere that it's important to allow the user to explicitly seed a PRNG; this allows for the use of one such PRNG per thread, for example, instead of seeding a new PRNG every time a random number is required. On Fri, Sep 8, 2017 at 11:52 AM, Alejandro Alonso via swift-evolution < [email protected]> wrote: > Hello swift evolution, I would like to propose a unified approach to > `random()` in Swift. I have a simple implementation here > https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5. This > implementation is a simple wrapper over existing random functions so > existing code bases will not be affected. Also, this approach introduces a > new random feature for Linux users that give them access to upper bounds, > as well as a lower bound for both Glibc and Darwin users. This change would > be implemented within Foundation. > > I believe this simple change could have a very positive impact on new > developers learning Swift and experienced developers being able to write > single random declarations. > > I’d like to hear about your ideas on this proposal, or any implementation > changes if need be. > > - Alejando > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
