> On Jun 24, 2016, at 6:38 AM, James Andrews via swift-dev
> <swift-dev@swift.org> wrote:
>
> Is there a reason why random() is missing from the standard library? Is
> it just a matter of someone implementing it?
(Note: I'm just a guy, not someone in a leadership position.)
Random number generation is surprisingly complicated:
* Is it a truly random number generator or a pseudorandom one?
* If it's truly random:
* Where are we getting the random data?
* Does it require platform-specific code?
* Is there I/O involved?
* If it's pseudorandom:
* What's our goal here—cryptography, statistics, both, neither?
Cryptographic PRNGs are slow for statistics, but statistical PRNGs break the
security of crypto algorithms.
* What algorithm?
* Does it use shared state, or do you initialize your own RNG instance?
* If it's shared:
* How does it behave under concurrency?
* Can you change the seed?
* If it's not shared:
* Can you seed it?
* How big is the seed?
* Where does the default seed come from?
* Can you save and restore the state?
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.
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.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
