<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">I'm okay with "unqualified" random being crypto-secure and qualifying non-crypto-secure generators as inferior, but I think that Unsafe is not the qualifier we are looking for. Everywhere else, Unsafe implies that misuse will cause unpredictable results/crashes, which is a different class of problems than the one that this tries to avoid. Maybe InsecureRandom? Pseudorandom? PredictableRandom?</div><div class=""><br class=""></div><div class="">The subtype relationships seem problematic to me: any UnsafeRandomSource is probably also a RandomSource. This means that you can't design an API requiring a RandomSource and assume that you'll get a crypto-secure one. Granted, anyone can pretend that their random is crypto-secure while it isn't, but I feel like this should be an important API hint.</div><div class=""><br class=""></div><div class="">I'm not convinced that `RandomSource` needs a `shared` property. By definition, you shouldn't be able to tell which RandomSource instance generated some random number, so it doesn't matter if you have multiple instances of it, or just one. It could be a flyweight and we'd be none the wiser. Requiring a shared instance also forces the implementation to be thread-safe, which is almost certainly not a desirable feature for an API meant to have a huge throughput.</div><div class=""><br class=""></div><div class="">To me, the tradeoff between "secure" and "insecure" seems to be that "secure" RNGs have an unpredictable result (which is suitable for crypto operations), and "insecure" RNGs can be seeded and repeated, which is a desirable feature in many scenarios. Then, there are some low-stake cases where that probably doesn't really matter (like in a dice-rolling app). That seems to be easy enough to represent with a base AnyRandomSource protocol, with sub-protocols RandomSource and PseudorandomSource (or whatever else seems to be a better name).</div><div class=""><br class=""></div><div class="">I think that there needs to be discussion about the random range for the static `random` properties. Right now, it can't return negative values, even for signed types. I feel that a random property on a type should use the entire domain of that type, and the range random properties can be used when you want a specific domain of values. If people aren't sure what Int.random or Double.random gets them, they won't use it, so I'd go for the simplest and most uniform possible definition for them: any finite value that the type can represent. (Also, your FixedWithInteger currently can't return Self.max, which I think is a bug.)</div><div class=""><br class=""></div><div class="">I have more comments, but it's getting late, so maybe I'll continue tomorrow.</div><div class=""><br class=""></div><div class="">Félix<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Le 25 sept. 2017 à 21:57, Alejandro Alonso via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<title class=""></title>
<div class="">
<div name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class="">
Hello evolution,
<div class=""><br class="">
</div>
<div class="">I am very thankful for all the feedback, and I’ve been working on a design that tries to utilize everybody’s ideas. The link to what I have so far is here: <a href="https://gist.github.com/Azoy/15f0518df38df9b722d4cb17bafea4c1" class="">https://gist.github.com/Azoy/15f0518df38df9b722d4cb17bafea4c1</a>.
Please keep in mind this is just a design, no actual implementation as I would most likely need assistance in doing. The default source for randomness will use the OS’s unseeded CSPRNG. This current setup exposes developers to an API that lets them create
their own RandomSources on the fly. I want to make the distinction that any existing or new sources of randomness that conform to UnsafeRandomSource are to be considered non cryptographically secure.</div>
<div class=""><br class="">
</div>
<div class="">I would love to get this discussion flowing again, and I would love input on the design. A few things I came across with this design is that some may want to use ranges as an argument for the numeric types, RandomAccessCollection returning an optional
when getting a random, and how to incorporate an API that allows distributions. I wanted to get input on how you feel about each of these topics as I’m indifferent about them all. I’m in no way saying this is the design we should go for, but I’m simply providing
something I think we should build on or talk about.</div>
</div>
<div name="messageSignatureSection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class="">
<br class="">
- Alejandro</div>
<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class="">
<br class="">
On Sep 8, 2017, 11:52 AM -0500, Alejandro Alonso via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>, wrote:<br class="">
<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;" class="">
<div name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class="">
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" class="">https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5</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 class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">I’d like to hear about your ideas on this proposal, or any implementation changes if need be.</div>
<div class=""><br class="">
</div>
<div class="">- Alejando</div>
</div>
<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class="">
<br class="">
<div class=""></div>
</div>
</blockquote>
</div>
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>