<div dir="ltr">Agreed. This simplification is more or less precisely the shape of the proposal that I was hoping for.<div><br></div><div>I'm worried that "optional" `random()` and "non-optional" `random()` are spelled the same way, especially as the type is not always obvious when, say, a range or collection is referred to by variable name and not as a literal. And I do think that may become even more problematic should we decide that some ranges (i.e., the countable ones) ought to conform to Collection. (But more on that later.)</div><div><br></div><div>But besides that concern (which, I would hope, should not be glossed over), I do like the direction of Nate's playground.<br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 8, 2018 at 5:37 PM, David Hart via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Unfortunately, it wasn’t my only worry. The simplifications from dropping Randomizable and random(in: ) are also very welcome for me.<div><div class="h5"><br><div><br><blockquote type="cite"><div>On 8 Jan 2018, at 23:08, Alejandro Alonso <<a href="mailto:aalonso128@outlook.com" target="_blank">aalonso128@outlook.com</a>> wrote:</div><br class="m_1151462705484370291Apple-interchange-newline"><div>
<div dir="auto">
I made changes last night that uses methods rather than properties if that’s all you’re worried about.<br>
<br>
<div>Sent from my iPhone</div>
<div><br>
On Jan 8, 2018, at 15:27, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>I much prefer the API from Nate Cook compared to the previous proposal. Its simpler, while still very powerful, and closer to Swift conventions (method instead of property).<br>
<div><br>
<blockquote type="cite">
<div>On 8 Jan 2018, at 20:02, Nate Cook via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div>
<br class="m_1151462705484370291Apple-interchange-newline">
<div>
<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>
<span id="m_1151462705484370291cid:5DA36848-BA9E-47D7-A914-2A585A07AED0@home"><Random.playground.zip></span>
<div style="word-wrap:break-word;line-break:after-white-space">
<div></div>
<div><br>
</div>
<div>
<div>
<blockquote type="cite">
<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_1151462705484370291Apple-interchange-newline">
<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">
<div><br>
<div>
<blockquote type="cite">
<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_1151462705484370291Apple-interchange-newline">
<div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps: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">
<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>
</blockquote>
</div>
<br>
</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>
</blockquote>
</div>
<br>
</div>
</blockquote>
<blockquote type="cite">
<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></blockquote></div><br></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>