I encourage anyone thinking about PRNG APIs to check out what C++ STL has to offer: http://en.cppreference.com/w/cpp/numeric/random
And this analysis/extension of it: http://www.pcg-random.org/posts/ease-of-use-without-loss-of-power.html Jacob On Sun, Apr 10, 2016 at 6:40 PM, Brent Royal-Gordon via swift-users < swift-users@swift.org> wrote: > > import Foundation > > > > (1..<4).sample > > [1,2,3].sample > > "abc".characters.sample > > ["a": 1, "b": 2, "c": 3].sample > > > > Like so many users of Swift, I have extensions of IntegerType, > ClosedInterval and CollectionType that avail me of the above methods and > their family, but I’d much rather if such extensions came with Darwin or at > least Foundation. > > I don't think a `sample` property or method is the right approach here. It > would be using some sort of global source of random numbers, which means > that: > > * It's not testable or repeatable > * It needs to be synchronized with other threads > * It can't be configured to use a different random number generator > > Personally, I would eventually like to see something like this in the > standard library: > > protocol RandomizerProtocol { > mutating func randomBytes(_ n: Int) -> [UInt8] > // or possibly something involving a generic-length tuple, > for speed > } > extension RandomizerProtocol { > // for coin flips > mutating func randomChoice() -> Bool { ... } > // for choosing a random element > mutating func randomChoice<CollectionType: > RandomAccessCollection>(from collection: CollectionType) -> > CollectionType.Element { ... } > // for choosing a random value from an uncountable range > (e.g. Range<Double>) > mutating func randomChoice<Element: Strideable>(from > range: Range<Element>) -> Element { ... } > } > struct Randomizer: RandomizerProtocol { > init(state: [UInt8]) { ... } > init() { self.init(state: > somethingToMakeAGoodRandomState()) } > > mutating func randomBytes(_ n: Int) -> [UInt8] { > // akin to arc4random() > } > } > > This would allow you to confine a random number generator to a particular > thread, swap one implementation for another, or inject one with a fixed > starting state as a dependency to make tests predictable. A design like > this one works around the problems I described nicely. > > However, I don't think this is a high enough priority to address right > now. This is borderline out-of-scope as "major new library functionality", > and there's so much stuff to do that is truly core to the language, this > simply seems like a distraction. > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > swift-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users >
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users