<div dir="ltr">I encourage anyone thinking about PRNG APIs to check out what C++ STL has to offer: <a href="http://en.cppreference.com/w/cpp/numeric/random">http://en.cppreference.com/w/cpp/numeric/random</a><div><br></div><div>And this analysis/extension of it: <a href="http://www.pcg-random.org/posts/ease-of-use-without-loss-of-power.html">http://www.pcg-random.org/posts/ease-of-use-without-loss-of-power.html</a></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>Jacob<br></div></div></div></div>
<br><div class="gmail_quote">On Sun, Apr 10, 2016 at 6:40 PM, Brent Royal-Gordon via swift-users <span dir="ltr"><<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> import Foundation<br>
><br>
> (1..<4).sample<br>
> [1,2,3].sample<br>
> "abc".characters.sample<br>
> ["a": 1, "b": 2, "c": 3].sample<br>
><br>
> 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.<br>
<br>
</span>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:<br>
<br>
* It's not testable or repeatable<br>
* It needs to be synchronized with other threads<br>
* It can't be configured to use a different random number generator<br>
<br>
Personally, I would eventually like to see something like this in the standard library:<br>
<br>
protocol RandomizerProtocol {<br>
mutating func randomBytes(_ n: Int) -> [UInt8]<br>
// or possibly something involving a generic-length tuple, for speed<br>
}<br>
extension RandomizerProtocol {<br>
// for coin flips<br>
mutating func randomChoice() -> Bool { ... }<br>
// for choosing a random element<br>
mutating func randomChoice<CollectionType: RandomAccessCollection>(from collection: CollectionType) -> CollectionType.Element { ... }<br>
// for choosing a random value from an uncountable range (e.g. Range<Double>)<br>
mutating func randomChoice<Element: Strideable>(from range: Range<Element>) -> Element { ... }<br>
}<br>
struct Randomizer: RandomizerProtocol {<br>
init(state: [UInt8]) { ... }<br>
init() { self.init(state: somethingToMakeAGoodRandomState()) }<br>
<br>
mutating func randomBytes(_ n: Int) -> [UInt8] {<br>
// akin to arc4random()<br>
}<br>
}<br>
<br>
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.<br>
<br>
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.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
swift-users mailing list<br>
<a href="mailto:swift-users@swift.org">swift-users@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-users</a><br>
</div></div></blockquote></div><br></div></div>