<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><div>Trouble is, most modern languages disagree with that and have chosen to split them out of their standard libraries.</div><div><br></div><div>- Rust <a href="https://github.com/rust-lang-nursery/rand">https://github.com/rust-lang-nursery/rand</a></div><div>- Go <a href="https://golang.org/pkg/math/rand/">https://golang.org/pkg/math/rand/</a></div><div>- Dart <a href="https://api.dartlang.org/stable/1.17.1/dart-math/Random-class.html">https://api.dartlang.org/stable/1.17.1/dart-math/Random-class.html</a></div><div>- Elm <a href="https://github.com/jcollard/elm-random">https://github.com/jcollard/elm-random</a></div><div>- Haskell <a href="http://hackage.haskell.org/package/random-1.1/docs/System-Random.html#">http://hackage.haskell.org/package/random-1.1/docs/System-Random.html#</a></div><div><br></div><div>As far as I can see, recent languages that do have [P]RNGs in their standard libraries are the ones that rely on massive STLs: Clojure, Scala, (java.*), C#, F# (.NET), Python, Ruby, (built-ins. Perhaps by virtue of their implementations in C).<br><br>Speaking as someone that has had to write such a control for a library, I don't think it should be included, at least not yet. Not because it's not useful, but because there doesn't seem to be a concrete plan for how it will work here to suit more than one use-case ("gimme a random number"). [P]RNGs are not one-size-fits-all and if the community upholds one particular implementation, it will uphold not just the good but the bad of the invariants it carries with it. Better to let the community offer a wide selection of algorithms and interfaces and let the user pick than let them reach for a tailor-made tool for a broad class of functionality.<br><br><div>~Robert Widmann</div></div><div><br>2016/07/03 5:37、James Andrews via swift-dev <<a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a>> のメッセージ:<br><br></div><blockquote type="cite"><div><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Thanks for the feedback. I agree in that I believe the standard library should be able to grow. I think a PRNG implementation is a sufficiently “atomic” building block to be included in the standard library for a modern language these days. </div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">As to the implementation, would it not be foolish to stray to far from the already well proven, existing well understood PRNG implementations?</div> <br> <div id="bloop_sign_1467548420347300096" class="bloop_sign"><span style="font-family:helvetica,arial;font-size:13px"></span>Thanks,<div>James</div><br>
</div> <br><p class="airmail_on">On 3 July 2016 at 07:46:16, Austin Zheng (<a href="mailto:austinzheng@gmail.com">austinzheng@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>I am also just a random guy, and I agree with much of what Brent says, but my personal opinion is that the standard library should be allowed to grow in the future to encompass areas whose generality and usefulness are comparable to those of current standard library constructs. I would consider a sufficiently well-designed suite of PRNGs to fall into this category.
<br>
<br>I guess what I'm saying is that, after Swift 3.0 is released, someone (maybe you!) should develop an argument as to why PRNGs belong in the standard library, and pitch it to the swift-evolution list. The worst that can happen is that people (or the core team) disagrees on principle, and at least you have an answer. But if there's interest a proposal can be drafted and taken to the review stage, at which point it'll be considered and possibly accepted.
<br>
<br>Best,
<br>Austin
<br>
<br>> On Jul 2, 2016, at 11:30 PM, Brent Royal-Gordon via swift-dev <<a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a>> wrote:
<br>>
<br>>> On Jun 24, 2016, at 6:38 AM, James Andrews via swift-dev <<a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a>> wrote:
<br>>>
<br>>> Is there a reason why random() is missing from the standard library? Is
<br>>> it just a matter of someone implementing it?
<br>>
<br>> (Note: I'm just a guy, not someone in a leadership position.)
<br>>
<br>> Random number generation is surprisingly complicated:
<br>>
<br>> * Is it a truly random number generator or a pseudorandom one?
<br>> * If it's truly random:
<br>> * Where are we getting the random data?
<br>> * Does it require platform-specific code?
<br>> * Is there I/O involved?
<br>> * If it's pseudorandom:
<br>> * What's our goal here—cryptography, statistics, both, neither? Cryptographic PRNGs are slow for statistics, but statistical PRNGs break the security of crypto algorithms.
<br>> * What algorithm?
<br>> * Does it use shared state, or do you initialize your own RNG instance?
<br>> * If it's shared:
<br>> * How does it behave under concurrency?
<br>> * Can you change the seed?
<br>> * If it's not shared:
<br>> * Can you seed it?
<br>> * How big is the seed?
<br>> * Where does the default seed come from?
<br>> * Can you save and restore the state?
<br>>
<br>> The Swift standard library is deep in very narrow, fundamental areas: features requiring compiler support, control flow, basic types, fundamental string handling, and sequences and collections. There's just barely enough console I/O and argument support to write a very basic command-line program. There's no file I/O, no concurrency, no networking, not even environment variables. Those things come from Foundation or from other libraries.
<br>>
<br>> Random-number generation is another one of those things that Swift leaves to libraries. It is complicated, platform-specific (but not generally architecture-specific), subject to app-specific requirements, implementable in userspace, and does not require compiler support. Ultimately, it simply *does not need to be part of the language* in the way the things in the standard library are. If we wanted to make a protocol for random number generators, we would pretty much just end up with Sequence or Collection, and we already have those sitting in the standard library. The rest is finicky details we can leave to platform creators, library implementors, and users while we work on the things only we can do, like improving our numeric protocols so we can support BigInts and BigFloats.
<br>>
<br>> --
<br>> Brent Royal-Gordon
<br>> Architechies
<br>>
<br>> _______________________________________________
<br>> swift-dev mailing list
<br>> <a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a>
<br>> <a href="https://lists.swift.org/mailman/listinfo/swift-dev">https://lists.swift.org/mailman/listinfo/swift-dev</a>
<br>
<br></div></div></span></blockquote></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-dev mailing list</span><br><span><a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-dev">https://lists.swift.org/mailman/listinfo/swift-dev</a></span><br></div></blockquote></div></body></html>