<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><blockquote type="cite" class=""><div class="">On Jan 11, 2018, at 9:17 PM, Alejandro Alonso <<a href="mailto:aalonso128@outlook.com" class="">aalonso128@outlook.com</a>> wrote:</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="">
Sorry it takes me forever to respond! I finally got around to writing this! School really takes all my time x)
<div class=""><br class="">
</div>
<div class="">I have a few ideas on where we can go with this:</div>
<div class=""><br class="">
</div>
<div class="">1. I agree, we should ditch `Randomizable` as something like that should belong in a separate library or written by the user.</div>
<div class=""><br class="">
</div>
<div class="">2. I also agree we should ditch the associated type on `RandomNumberGenerator`. I think we can sacrifice 32 bit generators using 64 bit ints to conform to the core team’s general use policy. This also makes default arguments for rngs possible which is
a +1 for me!</div>
<div class=""><br class="">
</div>
<div class="">I start to drift off from your design because `.random()` being an exception to ranges in that it’s inconsistent with other collection facilities and collection `.random()`. You make a few emails in the past that reference this as well. I think the right
move is to have the static functions utilize the ranges to provide non optional types.</div>
<div class=""><br class="">
</div>
<div class="">You wrote:</div>
<div class=""><br class="">
</div>
<div class="">“</div>
<div class="">I see a couple points in favor of these static methods (or initializers) on the numeric types:</div>
<div class=""><br class="">
</div>
<div class=""><span style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">1) The collection method will need to return an optional to match the semantics of existing methods (like min()). If this is the only method available, every time someone needs
a random value in the range 1...10, they’ll need to unwrap the result (with either force unwrapping, which people will complain about, or some kind of conditional binding, which is its own problem). Even if the semantics are the same (trapping on an empty
range), the user experience of using a non-optional method will be better.</span></div>
<pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class=""> </pre>
<div class=""><span style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">2) Floating-point ranges won’t get the collection method, so either we’ll have inconsistent APIs (random FP value is non-optional, random integer is optional) or we’ll make the
FP API optional just to match. Both of those seem bad.</span></div>
<div class="">”</div>
<div class=""><br class="">
</div>
<div class="">I believe this is the direction we need to go to keep consistency with collection based methods by justifying `.random(in:)` on the numeric types. With that in mind, Ben made a comment a long while ago saying, “<span style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">The
one downside is that you’d have to write 0..<Int.max. This might be a justification for a static property on one of the Integer protocols as shorthand for that.</span>” I believe this makes it perfectly justifiable for `.random()` on numeric types. This also
creates a consistency with `Bool.random()` making it justifiable for this as well. </div>
<div class=""><br class="">
</div>
<div class="">We can do all of this without `Randomizable` as well! Add extension methods on `FixedWidthInteger`, `BinaryFloatingPoint`, and `Bool`. These will be the methods that crash on an empty range, but we can precondition here to provide helpful debugging for
developers. You made reference to users using the range based api for a safe alternative if they needed optionals.</div>
<div class=""><br class="">
</div>
<div class="">```</div>
<div class="">// Here you can use something more runtime oriented (such as an array count)</div>
<div class="">guard let x = (0 ..< 5).random() else {</div>
<div class=""> fatalError(“not going to happen")<br class="">
</div>
<div class="">}</div>
<div class="">```</div>
<div class=""><br class="">
</div>
<div class="">I’m not too sure if you’ve had a change of heart, but I think the following is justifiable if we remove `Randomizable`.</div>
<div class=""><br class="">
</div>
<div class="">Sample Syntax:</div>
<div class="">```</div>
<div class="">// Full Int width (shorthand for Int.random(in: .min … .max))</div>
<div class="">Int.random()</div>
<div class=""><br class="">
</div>
<div class="">// random int from [0, 10)</div>
<div class="">Int.random(in: 0 ..< 10)</div>
<div class=""><br class="">
</div>
<div class="">// random double from [0, 1) (Modulo isn’t an issue here!)</div>
<div class="">Double.random()</div>
<div class=""><br class="">
</div>
<div class="">// random double from [0, .pi)</div>
<div class="">Double.random(in: 0 ..< .pi)</div>
<div class=""><br class="">
</div>
<div class="">// random boolean</div>
<div class="">Bool.random()</div>
<div class="">```</div>
<div class=""><br class="">
</div>
<div class="">This seems very consistent to me. The only inconsistency is with `Int.random()` covering the full width, and `Double.random()` covering only `[0, 1)`, but to me this functionality is very precedented in many other languages. Also by removing `Randomizable`,
other data types like `Data` don’t have to conform to a protocol, but can just add a random initializer that fits its needs.</div>
<div class=""><br class="">
</div>
<div class="">I think now is when people will start saying, “Int.random() bad, modulo bias, no no” x)</div>
<div class="">I see the potential for error here, but logically I’m thinking that so many other languages have this feature and I wonder if you think they all did it wrong too and shouldn’t have done so. This type of behavior is found in C, C++, C#, Java, etc. I agree
with Jonathon in that maybe we could suggest a warning/fixit in Xcode.</div>
<div class=""><br class="">
</div>
<div class="">tl;dr - Remove `Randomizable`, remove associated type on `RandomNumberGenerator`, be consistent with `.random()` with other properties and functions with every collection, preserve static `random()` and `random(in:)` syntax.</div></div></div></div></blockquote><div><br class=""></div><div>I would co-sign all of this except for preserving Int.random() and Double.random(), for the reasons I’ve laid out before, those Xiaodi responded with, and even the ergonomics of writing and reading code:</div><div><br class=""></div><div>- For floating-point values, if someone wants a [0, 1) range, I see no problem with having them write `Double.random(in: 0..<1)`. That’s still nice and short, and there’s no question about what kind of values are produced.</div><div><br class=""></div><div>- For integers, I see a basic breakdown into two use cases. First, there’s the case where you need a number in a specific range, for which the range-based methods are perfect. When you instead need a full-width integer, you’re generally using that integer as data, rather than as a value. The signedness of `Int` is a pain in that case, so you could either write `UInt64.random(in: .min ... .max)` or else access data from whatever generator you’re using—`Random.default.next()`.</div><div><br class=""></div><div>Also, from a discoverability and documentation perspective, I like having static `random` methods on the types that they generate. That feels like an easier pattern for a developer to recognize and use.</div><div><br class=""></div><div>Nate</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class="">
</div>
<div name="messageSignatureSection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class="">
- Alejandro</div>
<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class="">
<br class="">
On Jan 8, 2018, 1:02 PM -0600, Nate Cook 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 class="" style="word-wrap:break-word; line-break:after-white-space">I created a playground to explore this question, starting with a minimal subset of the proposal’s additions and building from there. The attached playground demonstrates what’s possible
with this subset on the first page, then uses subsequent pages to explore how the main random facilities of the C++ STL work under this model. (In my opinion, they work pretty well!)
<div class=""><br class="">
</div>
<div class="">The subset in the playground has three main differences from the proposal:</div>
<div class=""> - It doesn't include a <font face="Menlo" class="">Randomizable</font> protocol or a
<font face="Menlo" class="">random</font> property on numeric types.<br class="">
- It doesn't include the static <font face="Menlo" class="">random(in:)</font> methods on numeric types, either.<br class="">
- The <font face="Menlo" class="">RandomNumberGenerator</font> protocol doesn't have an associated type. Instead, it requires all conforming types to produce
<font face="Menlo" class="">UInt64</font> values.<br class="">
<br class="">
</div>
<div class="">I’ve tried to include a bit of real-world usage in the playground to demonstrate what writing code would look like with these additions. Please take a look!</div>
<div class=""><br class="">
</div>
<div class="">Nate</div>
<div class=""><br class="">
</div>
<div class=""></div>
</div>
<div class="" style="word-wrap:break-word; line-break:after-white-space">
<div class=""></div>
<div class=""><br class="">
</div>
<div class="">
<div class="">
<blockquote type="cite" class="" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #e67e22;">
<div class="">On Dec 2, 2017, at 9:50 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div>
<br class="x_Apple-interchange-newline">
<div class="">
<div dir="auto" class="">I don’t have much to say about this other than that I think the discussion seems way too narrow, focusing on spelling rather than on functionality and composability. I consider the “generic random number library” design to be a mostly-solved
problem, in <span class="" style="background-color:rgba(255,255,255,0)">the C++ standard library (<a href="http://en.cppreference.com/w/cpp/numeric/random" class="">http://en.cppreference.com/w/cpp/numeric/random</a>). </span>Whatever goes into the Swift
standard library does not need to have all those features right away, but should support being extended into something having the same general shape. IMO the right design strategy is to
<u class="">implement and use</u> a Swift version of C++’s facilities and only then consider proposing [perhaps a subset of] that design for standardization in Swift.
<div class="">
<div class=""><br class="">
</div>
<div class="">Sent from my iPad
<div class=""><br class="">
On Dec 2, 2017, at 5:12 PM, Kyle Murray via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
<br class="">
</div>
<blockquote type="cite" class="" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #3498db;">
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #d35400;">
<div class="">On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div>
<br class="x_Apple-interchange-newline">
<div class=""><span class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; float:none; display:inline!important">Instead,
we ought to make clear to users both the features and the limitations of this API, to encourage use where suitable and to discourage use where unsuitable.</span></div>
</blockquote>
</div>
<br class="">
<div class="">I like that you're considering the balance here. I've been lightly following this thread and want to add my thoughts on keeping crypto and pseudorandomness out of the name of at least one
<font face="Menlo" class="">random</font> API intended for general use.</div>
<div class=""><br class="">
</div>
<div class="">For someone who doesn't know or care about the subtleties of insecure or pseudorandom numbers, I'm not sure that the name
<font face="Menlo" class="">insecureRandom</font> is effectively much different than
<font face="Menlo" class="">badRandom</font>, at least in terms of the information it conveys to non-experts. To Greg's point, that's the opposite of the signal that the API name should suggest because it's what most people should use most of the time. As you
say, this API is being designed for general use.</div>
<div class=""><br class="">
</div>
<div class="">There's a cost to adding extra complexity to names, too. I don't think it's far-fetched to suspect that people who find
<font face="Menlo" class="">insecureRandom</font> in an autocomplete listing or search will think "Where's the plain random function?"... and then go looking for a community extension that will inevitably provide a trivial alias: <font face="Menlo" class="">func
random() { return insecureRandom() }</font>. That's the sort of adoption I'd expect from something for new programmers, like Swift Playgrounds. Someone's introduction to randomness in programming should probably involve no more than a straightforward mapping
from the elementary definition, rather than forcing a teaching moment from more advanced math.</div>
<div class=""><br class="">
</div>
<div class="">I think there are better places for caveat information than in the API names themselves; documentation being one clear destination. This is in contrast with <font face="Menlo" class="">Unsafe*Pointer</font>, where the safety element is critical
enough to be elevated to be more than caveat-level information. You can go really far and create really cool things before these caveats start to apply. Using randomness as a black box in an intro programming environment seems like a much more common scenario
than someone attempting to roll their first crypto by only reading API names and hoping for the best.</div>
<div class=""><br class="">
</div>
<div class="">-Kyle</div>
</div>
</blockquote>
<blockquote type="cite" class="" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #3498db;">
<div class=""><span class="">_______________________________________________</span><br class="">
<span class="">swift-evolution mailing list</span><br class="">
<span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class="">
<span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class="">
</div>
</blockquote>
</div>
</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="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
</div>
</div></blockquote></div><br class=""></body></html>