<div dir="ltr">Internally, I know that Swift has a Linux shim for arc4random. However, it&#39;s unlikely that any modern random number generator facility in Swift would rely on arc4random in such a way.<div><br></div><div>This topic has been broached on Swift Evolution previously. It&#39;s interesting to me that Steve Canon is so certain that CSPRNGs are the way to go. I wasn&#39;t aware that hardware CSPRNGs have come such a long way and are so ubiquitous as to be feasible as a basis for Swift random numbers. If so, great.</div><div><br></div><div>Otherwise, if there is any way that a software, non-cryptographically secure PRNG is going to outperform a CSPRNG, then I think it&#39;s worthwhile to have a (carefully documented) choice between the two. I would imagine that for many uses, such as an animation in which you need a plausible source of noise to render a flame, whether that is cryptographically secure or not is absolutely irrelevant but performance may be key.</div><div><br></div><div>I have implemented Xorshift128+ and Xoroshiro128+ in a Swift numerics library here:</div><div><a href="https://github.com/xwu/NumericAnnex/tree/master/Sources">https://github.com/xwu/NumericAnnex/tree/master/Sources</a><br></div><div><br></div><div>They are, of course, *non*-cryptographically secure random number generator algorithms, but these implementations rely on the hardware for a cryptographically secure seed. A (useless) vignette for how my classes would be used is:</div><div><br></div><div>```</div><div><div>let random = Random()!</div><div>// Initializing a `Random` from a cryptographically secure random seed may fail,</div><div>// since it is possible that the system may not have enough entropy. Better to be</div><div>// transparent about this than to proceed with some sort of less-than-secure</div><div>// alternative source of entropy.</div><div><br></div><div>let x = random.uniform() as Int</div><div><br></div><div>// You can also pass the desired result type as an argument.</div><div>let y = random.uniform(Int.self)</div><div><br></div><div>if x &gt; y {</div><div>  print(&quot;Here&#39;s a random value between 0 and 42 (inclusive):&quot;)</div><div>  print(random.uniform(a: 0, b: 42))</div><div>} else {</div><div>  print(&quot;Here&#39;s a random value between -42 and 0 (inclusive):&quot;)</div><div>  print(random.uniform(a: -42, b: 0))</div><div>}</div></div><div class="gmail_extra">```</div><div class="gmail_extra"><br></div><div class="gmail_extra">If you look through the design of the `PRNG` protocol, you&#39;ll see how easy it is to implement functions that return a sequence of random values, in some desired distribution. The overall design is inspired by the C++ STL random number generator APIs, as well as some very cogent commentary on how the C++ STL random number generator APIs are unnecessarily complicated. No matter how far we simplify, though, I agree with commentators elsewhere that it&#39;s important to allow the user to explicitly seed a PRNG; this allows for the use of one such PRNG per thread, for example, instead of seeding a new PRNG every time a random number is required.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 8, 2017 at 11:52 AM, Alejandro Alonso via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">




<div>
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
Hello swift evolution, I would like to propose a unified approach to `random()` in Swift. I have a simple implementation here <a href="https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5" target="_blank">https://gist.github.com/<wbr>Azoy/<wbr>5d294148c8b97d20b96ee64f434bb4<wbr>f5</a>.
 This implementation is a simple wrapper over existing random functions so existing code bases will not be affected. Also, this approach introduces a new random feature for Linux users that give them access to upper bounds, as well as a lower bound for both
 Glibc and Darwin users. This change would be implemented within Foundation.
<div><br>
</div>
<div>I believe this simple change could have a very positive impact on new developers learning Swift and experienced developers being able to write single random declarations.</div>
<div><br>
</div>
<div>I’d like to hear about your ideas on this proposal, or any implementation changes if need be.</div>
<div><br>
</div>
<div>- Alejando</div>
</div>
<div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<br>
<div></div>
</div>
</div>

<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>