You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// Returns a random BinaryFloatingPoint within lowerBound and upperBound (uses Random.default)
269
-
publicvar random: Bound? {
269
+
publicfuncrandom() -> Bound? {
270
270
returnself.random(using: Random.default)
271
271
}
272
272
@@ -281,7 +281,7 @@ public protocol Randomizable {
281
281
282
282
extensionRandomizable {
283
283
// Enables the shortcut for uses like Int.random
284
-
publicstaticvar random:Self {
284
+
publicstaticfuncrandom() ->Self {
285
285
returnself.random(using: Random.default)
286
286
}
287
287
}
@@ -451,16 +451,16 @@ Swift is a safe language which means that it shouldn't be encouraging non-experi
451
451
452
452
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.
453
453
454
-
### Rename Collection.random to Collection.randomElement
454
+
### Rename Collection.random() to Collection.randomElement()
455
455
456
-
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`.
456
+
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()`.
457
457
458
-
### Remove T.random
458
+
### Remove T.random()
459
459
460
460
This was a pretty discussed topic that I disagreed with heavily.
461
461
462
-
`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.
462
+
`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.
463
463
464
-
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.
464
+
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.
465
465
466
466
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.
0 commit comments