# SE-0202: Random Unification

**URL:** <https://forums.swift.org/t/se-0202-random-unification/11313>\
**Category:** Proposal Reviews\
**Created:** [March 23, 2018, 7:57pm UTC](https://forums.swift.org/t/se-0202-random-unification/11313 "2018-03-23T19:57:47Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [March 23, 2018, 9:47pm UTC](https://forums.swift.org/t/se-0202-random-unification/11313/4 "2018-03-23T21:47:46Z")

</div>

There is a lot to cover here (the pre-proposal [discussion thread](https://forums.swift.org/t/proposal-random-unification/6626) has well over 200 posts!)

First, the text of the proposal itself could use a little work. One example is where the main protocol `RandomNumberGenerator` is described:

> [@](#):
>
> ```swift
> public protocol RandomNumberGenerator {
> // This determines the functionality for producing a random number.
> // Required to implement by all rngs.
> func next() -> UInt64
> }
> 
> // These sets of functions are not required and are provided by the stdlib by default
> extension RandomNumberGenerator {
> // This function provides generators a way of generating other unsigned integer types
> public func next<T : FixedWidthInteger & UnsignedInteger>() -> T
> 
> // This function provides generators a mechanism for uniformly generating a number from 0 to upperBound
> // Developers can extend this function themselves and create different behaviors for different distributions
> public func next<T : FixedWidthInteger & UnsignedInteger>(upperBound: T) -> T
> }
> 
> ```

It is not clear whether conforming types are intended to be able to provide their own implementations for the two `next<T>()` methods described in the extension. As written, they are \*not\* able to, but the comments seem to imply that they should be.

• • •

One major decision in the proposal is to make the default random number generator cryptographically secure. I think we should explore the possibility of providing both a secure generator and a fast generator in the standard library.

• • •

It is not immediately clear how non-uniform distributions fit with the proposal. The normal distribution in particular is used quite frequently, and I would hope that a gaussian generator could be a “drop-in replacement”, at least for floating-point value.

In fact, we should consider including in the standard library some way to generate normally-distributed values, with the ability to specify a generator (eg. “fast” or “secure”) as well as a mean and standard deviation (with default values).

• • •

The proposed syntax for generating a random integer or float less than some upper bound is rather verbose:

```swift
Int.random(in: 0..<n)
Double.random(in: 0..<x)

```

I would like to see a free function along the lines of:

```swift
func random<T: FixedWidthInteger>(_ upperBound: T) -> T
  where: /*insert constraints here*/
{
  return T.random(in: 0..<upperBound)
}

```

And the same thing for `BinaryFloatingPoint`, so that you can write, eg:

```swift
random(n)

```

and have it do the correct thing. Note that I am \*not\* asking for the zero-argument version which leads people into the modulo-bias morass, nor for a type-converting version. This function takes one argument (and perhaps an optional generator) and returns a value of the same type as its argument.

Similarly, a free function that takes a range would be nice, and might even supplant the `random(n)` version entirely:

```swift
random(0...15)

```

My main point here is that repeating type information is unnecessary, inelegant, and non-Swifty. Putting the base implementation in static functions is great for encapsulation, and I support that decision. However, the lack of a free function makes use-sites needlessly verbose.

Having a free function with a simple, well-known name makes it easy to reach for the right tool. And if we introduce a protocol (eg. `Randomizable`) for types with `static func random(…)`, then that free function could be a single simple trampoline.

---

_[View the full topic](https://forums.swift.org/t/se-0202-random-unification/11313)._