[Accepted] SE-202: Random Unification

The core team has accepted this proposal, with the following revisions:

  • The method to get a random element from a collection should be named Collection.randomElement() -> Element?

  • Since not all platforms will be able to provide an implementation of random that’s a cryptographically secure source of randomness, and that different platforms and users have different priorities, the decision of exactly which implementation to use for the default random number generator will be left to that platform’s implementation of Swift. Where a platform vendor recommends certain sources of randomness, that should be preferred. Note that users should not rely on a particular implementation:
    we intentionally give the vendor permission to change the implementation in the future.

    The standard library should document the implementation used on each platform. The recommendation is that it should aspire to being cryptographically secure and provide a high quality source of randomness, balanced with a need for reasonable performance. When the vendor cannot achieve these goals, they should document it.

  • The core team decided to keep the proposal’s use of static methods. While the use of a free function may help with discoverability, it would lead to a proliferation of overloaded free functions for generating random values for other types. In particular, “full-width” random functions, such as for a Bool, would require overloading purely by return type with a free function.

  • The random number generator argument should be taken inout. This is in keeping with other similar parts of the language (such as the recently accepted Hasher), will allow for value-typed stateful generators, and in the future, move-only generators.

Thanks again to everyone for participating in the review!

25 Likes
Terms of Service

Privacy Policy

Cookie Policy