<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
I am willing to give `.random()`. However I still wish to preserve `.random(in:)` and `.random()` on Bool.<br>
<br>
<div id="AppleMailSignature">Sent from my iPhone</div>
<div><br>
On Jan 11, 2018, at 21:28, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">On Thu, Jan 11, 2018 at 9:17 PM, Alejandro Alonso via swift-evolution
<span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
Sorry it takes me forever to respond! I finally got around to writing this! School really takes all my time x)
<div><br>
</div>
<div>I have a few ideas on where we can go with this:</div>
<div><br>
</div>
<div>1. I agree, we should ditch `Randomizable` as something like that should belong in a separate library or written by the user.</div>
<div><br>
</div>
<div>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><br>
</div>
<div>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><br>
</div>
<div>You wrote:</div>
<div><br>
</div>
<div>“</div>
<div>I see a couple points in favor of these static methods (or initializers) on the numeric types:</div>
<div><br>
</div>
<div><span style="white-space:pre-wrap;background-color:rgb(255,255,255)">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)"> </pre>
<div><span style="white-space:pre-wrap;background-color:rgb(255,255,255)">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>”</div>
<div><br>
</div>
<div>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)">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><br>
</div>
<div>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><br>
</div>
<div>```</div>
<div>// Here you can use something more runtime oriented (such as an array count)</div>
<div>guard let x = (0 ..< 5).random() else {</div>
<div> fatalError(“not going to happen")<br>
</div>
<div>}</div>
<div>```</div>
<div><br>
</div>
<div>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><br>
</div>
<div>Sample Syntax:</div>
<div>```</div>
<div>// Full Int width (shorthand for Int.random(in: .min … .max))</div>
<div>Int.random()</div>
<div><br>
</div>
<div>// random int from [0, 10)</div>
<div>Int.random(in: 0 ..< 10)</div>
<div><br>
</div>
<div>// random double from [0, 1) (Modulo isn’t an issue here!)</div>
<div>Double.random()</div>
<div><br>
</div>
<div>// random double from [0, .pi)</div>
<div>Double.random(in: 0 ..< .pi)</div>
<div><br>
</div>
<div>// random boolean</div>
<div>Bool.random()</div>
<div>```</div>
<div><br>
</div>
<div>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><br>
</div>
<div>I think now is when people will start saying, “Int.random() bad, modulo bias, no no” x)</div>
<div>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.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>You will have noted, surely, the evidence given above that in Apple's internal code the majority of uses of APIs equivalent to `Int.random()` are erroneous due to unintended modulo bias. Yes, what that would imply is that all the other languages did it
wrong. Why do you feel it is so important to have a shorthand that enables no additional behavior in the face of overwhelming evidence that it is actively harmful?</div>
<div><br>
</div>
<div>Likewise, you acknowledge the inconsistency of Int.random() and Double.random(), yet again suggest a shorthand that enables no additional behavior in spite of the potential for misunderstanding. What advantage of having such an API do you see which could
overcome this very glaring drawback?</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<div>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><br>
</div>
<div>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 name="messageSignatureSection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<br>
- Alejandro</div>
<div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<div>
<div class="h5"><br>
On Jan 8, 2018, 1:02 PM -0600, Nate Cook via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>, wrote:<br>
</div>
</div>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #1abc9c">
<div>
<div class="h5">
<div 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><br>
</div>
<div>The subset in the playground has three main differences from the proposal:</div>
<div> - It doesn't include a <font face="Menlo">Randomizable</font> protocol or a
<font face="Menlo">random</font> property on numeric types.<br>
- It doesn't include the static <font face="Menlo">random(in:)</font> methods on numeric types, either.<br>
- The <font face="Menlo">RandomNumberGenerator</font> protocol doesn't have an associated type. Instead, it requires all conforming types to produce
<font face="Menlo">UInt64</font> values.<br>
<br>
</div>
<div>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><br>
</div>
<div>Nate</div>
<div><br>
</div>
<div></div>
</div>
</div>
</div>
<div style="word-wrap:break-word;line-break:after-white-space">
<div></div>
<div><br>
</div>
<div>
<div>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #e67e22">
<span class="">
<div>On Dec 2, 2017, at 9:50 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div>
<br class="m_-1976562250433445391x_Apple-interchange-newline">
</span>
<div>
<div class="h5">
<div>
<div dir="auto">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 style="background-color:rgba(255,255,255,0)">the C++ standard library (<a href="http://en.cppreference.com/w/cpp/numeric/random" target="_blank">http://en.cppreference.com/w/<wbr>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>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>
<div><br>
</div>
<div>Sent from my iPad
<div><br>
On Dec 2, 2017, at 5:12 PM, Kyle Murray via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
<br>
</div>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #3498db">
<div><br>
<div>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #d35400">
<div>On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div>
<br class="m_-1976562250433445391x_Apple-interchange-newline">
<div><span 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>
<div>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">random</font> API intended for general use.</div>
<div><br>
</div>
<div>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">insecureRandom</font> is effectively much different than <font face="Menlo">
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><br>
</div>
<div>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">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">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><br>
</div>
<div>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">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><br>
</div>
<div>-Kyle</div>
</div>
</blockquote>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #3498db">
<div><span>______________________________<wbr>_________________</span><br>
<span>swift-evolution mailing list</span><br>
<span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br>
<span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a></span><br>
</div>
</blockquote>
</div>
</div>
</div>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</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>
</div>
</blockquote>
</body>
</html>