Make .random a function

Fix last few .random

Author: Azoy

proposals/nnnn-random-unification.md

@@ -112,7 +112,7 @@ Next, we will make `FixedWidthInteger`, `BinaryFloatingPoint`, and `Bool` confor
 // The following utilizes each integer's full range extent (T.min ... T.max)
 
 // Utilizes the standard library's default random (alias to Int.random(using: Random.default))
-let randomInt = Int.random
+let randomInt = Int.random()
 let randomUInt = UInt.random(using: myCustomRandomNumberGenerator)
 
 // The following is extended for types that conform to both Randomizable and Strideable
@@ -126,7 +126,7 @@ let randomUIntFrom10Through100 = UInt.random(in: 10 ... 100, using: myCustomRand
 // For floating points, the range is set to 0 to 1 exclusive
 
 // Utilizes the standard library's default random (alias to Float.random(using: Random.default))
-let randomFloat = Float.random
+let randomFloat = Float.random()
 let randomDouble = Double.random(using: myCustomRandomNumberGenerator)
 
 // The following is extended for types that conform to both Randomizable and BinaryFloatingPoint
@@ -138,18 +138,18 @@ let randomDoubleFrom0Through5 = Double.random(in: 0.0 ... 5.0, using: myCustomRa
 `Bool` example:
 ```swift
 // Utilizes the standard library's default random (alias to Bool.random(using: Random.default))
-let randomBool1 = Bool.random
+let randomBool1 = Bool.random()
 let randomBool2 = Bool.random(using: myCustomRandomNumberGenerator)
 ```
 
-For `Collection` we add the random property and method onto `Collection` itself, then add default implementation along with it.
+For `Collection` we add the random method onto `Collection` itself, then add default implementation along with it.
 
 `Collection` example:
 ```swift
 let greetings = ["hey", "hi", "hello", "hola"]
 
 // Utilizes the standard library's default random (alias to greetings.random(using: Random.default))
-print(greetings.random as Any) // This returns an Optional
+print(greetings.random() as Any) // This returns an Optional
 print(greetings.random(using: myCustomRandomNumberGenerator) as Any) // This returns an Optional
 ```
 
@@ -160,7 +160,7 @@ For `Range` and `ClosedRange` we extend these types and add this functionality i
 let numbers = 0.0 ..< 5.0
 
 // Utilizes the standard library's default random (alias to numbers.random(using: Random.default))
-print(numbers.random as Any) // This returns an Optional
+print(numbers.random() as Any) // This returns an Optional
 print(numbers.random(using: myCustomRandomNumberGenerator) as Any) // This returns an Optional
 ```
 
@@ -169,7 +169,7 @@ print(numbers.random(using: myCustomRandomNumberGenerator) as Any) // This retur
 let numbers = 0.0 ... 5.0
 
 // Utilizes the standard library's default random (alias to numbers.random(using: Random.default))
-print(numbers.random as Any) // This returns an Optional
+print(numbers.random() as Any) // This returns an Optional
 print(numbers.random(using: myCustomRandomNumberGenerator) as Any) // This returns an Optional
 ```
 
@@ -231,7 +231,7 @@ public struct Random : RandomNumberGenerator {
 public protocol Collection {
   // Returns a random element from the collection (uses Random.default)
   // Can return an Optional if isEmpty is true
-  var random: Element? { get }
+  func random() -> Element?
 
   // Returns a random element from the collection (uses the rng provided)
   // Can return an Optional if isEmpty is true
@@ -240,7 +240,7 @@ public protocol Collection {
 
 extension Collection {
   // Default implementation
-  public var random: Element? {
+  public func random() -> Element? {
     return self.random(using: Random.default)
   }
 
@@ -253,7 +253,7 @@ extension Collection {
 // this to make sure users can do things like (5.0 ..< 12.0).random
 extension Range where Bound : BinaryFloatingPoint {
   // Returns a random BinaryFloatingPoint within lowerBound and upperBound (uses Random.default)
-  public var random: Bound? {
+  public func random() -> Bound? {
     return self.random(using: Random.default)
   }
 
@@ -266,7 +266,7 @@ extension Range where Bound : BinaryFloatingPoint {
 // this to make sure users can do things like (5.0 ... 12.0).random
 extension ClosedRange where Bound : BinaryFloatingPoint {
   // Returns a random BinaryFloatingPoint within lowerBound and upperBound (uses Random.default)
-  public var random: Bound? {
+  public func random() -> Bound? {
     return self.random(using: Random.default)
   }
 
@@ -281,7 +281,7 @@ public protocol Randomizable {
 
 extension Randomizable {
   // Enables the shortcut for uses like Int.random
-  public static var random: Self {
+  public static func random() -> Self {
     return self.random(using: Random.default)
   }
 }
@@ -291,14 +291,14 @@ extension Randomizable {
 // this returns a non-optional. Ranges get the benefit of using random, but this is the preferred
 // method as it provides a cleaner API to users and clearly expresses the operation.
 // It is worth noting that any empty range entered here will abort the program.
-// We do this to preserve a clean API which may help steer people from T.random % num (where T: BinaryInteger)
+// We do this to preserve a clean API which may help steer people from T.random() % num (where T: BinaryInteger)
 // For those that are that unsure whether or not their range is empty or not,
 // they can simply call random from the range itself to produce an Optional, or if/guard check
 // whether or not the range is empty beforehand, then use these functions.
 extension Randomizable where Self: BinaryFloatingPoint {
   // Utilizes Random.default
   public static func random(in range: Range<Self>) -> Self {
-    return range.random!
+    return range.random()!
   }
 
   // Utilizes the rng provided
@@ -311,7 +311,7 @@ extension Randomizable where Self: BinaryFloatingPoint {
 
   // Utilizes Random.default
   public static func random(in range: ClosedRange<Self>) -> Self {
-    return range.random!
+    return range.random()!
   }
 
   // Utilizes the rng provided
@@ -328,14 +328,14 @@ extension Randomizable where Self: BinaryFloatingPoint {
 // this returns a non-optional. Ranges get the benefit of using random, but this is the preferred
 // method as it provides a cleaner API to users and clearly expresses the operation.
 // It is worth noting that any empty range entered here will abort the program.
-// We do this to preserve a clean API which may help steer people from T.random % num (where T: BinaryInteger)
+// We do this to preserve a clean API which may help steer people from T.random() % num (where T: BinaryInteger)
 // For those that are that unsure whether or not their range is empty or not,
 // they can simply call random from the range itself to produce an Optional, or if/guard check
 // whether or not the range is empty beforehand, then use these functions.
 extension Randomizable where Self: Strideable, Self.Stride: SignedInteger {
   // Utilizes Random.default
   public static func random(in range: CountableRange<Self>) -> Self {
-    return range.random!
+    return range.random()!
   }
 
   // Utilizes the rng provided
@@ -348,7 +348,7 @@ extension Randomizable where Self: Strideable, Self.Stride: SignedInteger {
 
   // Utilizes Random.default
   public static func random(in range: CountableClosedRange<Self>) -> Self {
-    return range.random!
+    return range.random()!
   }
 
   // Utilizes the rng provided
@@ -428,7 +428,7 @@ I spent a lot of time deciding what to do if it failed. Ultimately it came down
 In a world where this did return an error to Swift, it would require types that implement `Randomizable` to return Optionals as well.
 
 ```swift
-let random = Int.random!
+let random = Int.random()!
 ```
 
 "I just want a random number, what is this ! the compiler is telling me to add?"
@@ -451,16 +451,16 @@ Swift is a safe language which means that it shouldn't be encouraging non-experi
 
 It has been discussed to give this a name such as `RNG`. I went with `RandomNumberGenerator` because it is concise, whereas `RNG` has a level of obscurity to those who don't know the acronym.
 
-### Rename Collection.random to Collection.randomElement
+### Rename Collection.random() to Collection.randomElement()
 
-I chose `.random` over `.randomElement` here because `.randomElement` doesn't match with things like `.first` and `.last`. If the naming for those facilities were `.firstElement` and `.lastElement` then I would have chosen `.randomElement`, but to be consistent I chose `.random`.
+I chose `.random()` over `.randomElement()` here because `.randomElement()` doesn't match with things like `.first` and `.last`. If the naming for those facilities were `.firstElement` and `.lastElement` then I would have chosen `.randomElement()`, but to be consistent I chose `.random()`.
 
-### Remove T.random
+### Remove T.random()
 
 This was a pretty discussed topic that I disagreed with heavily.
 
-`T.random` is **always** followed by modulus, remove this in favor of `T.random(in:)`. The argument here is that introducing `T.random` opens up the error for modulo bias which does not provide uniformity. While I do see the concern here, I don't believe removing `T.random` is the answer.
+`T.random()` is **always** followed by modulus, remove this in favor of `T.random(in:)`. The argument here is that introducing `T.random()` opens up the error for modulo bias which does not provide uniformity. While I do see the concern here, I don't believe removing `T.random()` is the answer.
 
-Modulo bias is only a concern to types where they conform to `BinaryInteger`. Types that implement `Randomizable` and not `BinaryInteger` shouldn't have this functionality removed. Not only that, `T.random` is the core purpose of `Randomizable`. Typing `Int.random` in an autocorrect IDE (Xcode) would also reveal `.random(in:)` which should help prevent abuse.
+Modulo bias is only a concern to types where they conform to `BinaryInteger`. Types that implement `Randomizable` and not `BinaryInteger` shouldn't have this functionality removed. Not only that, `T.random()` is the core purpose of `Randomizable`. Typing `Int.random()` in an autocorrect IDE (Xcode) would also reveal `.random(in:)` which should help prevent abuse.
 
-A proposed solution to this is to just have users do `Int.random(in: Int.min ... Int.max)`. This doesn't work in the first place because internally collections utilize the `count` property to determine the upperBound, and `count` isn't expressible for this range as it exceeds `Int`'s range. For developers that need this functionality, the solution for them is something like this: `Int(truncatingIfNeeded: Random.default.next(UInt.self))`. 1. This doesn't clearly express the operation used here and 2. Creates another pain point for Swift. As the goal of this proposal is to remove pain points regarding random, removing `T.random` does the oppposite and introduces some pain points.
+A proposed solution to this is to just have users do `Int.random(in: Int.min ... Int.max)`. This doesn't work in the first place because internally collections utilize the `count` property to determine the upperBound, and `count` isn't expressible for this range as it exceeds `Int`'s range. For developers that need this functionality, the solution for them is something like this: `Int(truncatingIfNeeded: Random.default.next(UInt.self))`. 1. This doesn't clearly express the operation used here and 2. Creates another pain point for Swift. As the goal of this proposal is to remove pain points regarding random, removing `T.random()` does the oppposite and introduces some pain points.