<div dir="ltr">On Sat, Dec 2, 2017 at 12:23 AM, David Waite <span dir="ltr">&lt;<a href="mailto:david@alkaline-solutions.com" target="_blank">david@alkaline-solutions.com</a>&gt;</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 style="word-wrap:break-word;line-break:after-white-space"><span class=""><br><div><br><blockquote type="cite"><div>On Dec 1, 2017, at 11:05 AM, Erica Sadun via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_-6633297036476696279Apple-interchange-newline"><div><div 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">I&#39;d like to put forth that Gameplay Kit offers a perfectly cromulent model of random number generation and API. Why not take that as a starting point, Swiftify it so it becomes a cross platform solution, and then apply the specific questions of sequences, collections, and indices as a second step?  </div><div 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"><br></div><div 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">I don&#39;t support intermingling random functionality with existing core types.</div><br class="m_-6633297036476696279Apple-interchange-newline"></div></blockquote></div><br></span><div>GameplayKit randomization has a number of API deficiencies that we can’t easily/efficiently solve by wrapping it in Swift.</div><div><br></div><div>Most significantly, it is not designed to support any cryptographic operations (which I believe is why they never added a nextBytes() or equivalent method).</div><div><br></div><div>For GameplayKit this is fine - the design focuses on being able to get the distribution appropriate for your game, and being able to have identical pseudorandom number sequences for each device in a multiplayer scenario. They went as far as to require all random sources to support NSSecureCoding so that they may be persisted and/or serialized over the wire, which precludes a GKRandomSource from being based on the system random sources.</div></div></blockquote><div><br></div><div>That said, I am not sure that this proposal should give any pretense of being suitable for cryptographic use. On implementation, the code will not have been audited for that purpose, although the author very rightly attempts to use the &quot;best&quot; possible sources of entropy available for each platform. Perhaps explicitly _not_ supporting cryptographic operations is the more Swifty way to go (in the sense that, where possible, Swift API design aims to help users avoid footguns).</div><div><br></div><div><br></div></div></div></div>