Random() in the standard library

Hi,

Is there a reason why random() is missing from the standard library? Is
it just a matter of someone implementing it?

Thanks,
James

(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.

···

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?

--
Brent Royal-Gordon
Architechies

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.

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.

Best,
Austin

···

On Jul 2, 2016, at 11:30 PM, Brent Royal-Gordon via swift-dev <swift-dev@swift.org> wrote:

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

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.

As to the implementation, would it not be foolish to stray to far from the already well proven, existing well understood PRNG implementations?

Thanks,
James

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.

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.

Best,
Austin

···

On 3 July 2016 at 07:46:16, Austin Zheng (austinzheng@gmail.com) wrote:

On Jul 2, 2016, at 11:30 PM, Brent Royal-Gordon via swift-dev <swift-dev@swift.org> wrote:

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

Trouble is, most modern languages disagree with that and have chosen to split them out of their standard libraries.

- Rust GitHub - rust-random/rand: A Rust library for random number generation.
- Go rand package - math/rand - Go Packages
- Dart Random class - dart:math library - Dart API
- Elm GitHub - jcollard/elm-random: Seed based random numbers in Elm
- Haskell System.Random

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).

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.

~Robert Widmann

2016/07/03 5:37、James Andrews via swift-dev <swift-dev@swift.org> のメッセージ:

···

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.

As to the implementation, would it not be foolish to stray to far from the already well proven, existing well understood PRNG implementations?

Thanks,
James

On 3 July 2016 at 07:46:16, Austin Zheng (austinzheng@gmail.com) wrote:

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.

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.

Best,
Austin

> On Jul 2, 2016, at 11:30 PM, Brent Royal-Gordon via swift-dev <swift-dev@swift.org> wrote:
>
>> 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

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

C++11 defines PRNGs in the STL, but even then the API is fairly complex thanks to the need for so many different options for source, distribution, seeds, security... - and it *still* doesn’t cover all of what I consider the obvious cases (YMMV).

I agree with Robert here, Swift isn’t ready to have that heavy a functionality be part of its core library. For that matter, I question if it’s even a question of readiness so much as one of the API being suitable to a stdlib at all! Having the basic tools available via Darwin/Glibc and/or Foundation is plenty. If you have a need for stronger guarantees in your entropy than you can get from the common functions like rand, random, *rand48, arc4random, etc., it’s unlikely that any stdlib-provided option is going to meet your needs anyway.

I mean, not that I don’t wish there was something like ***SSL’s RAND functionality around, but that just underscores the heck out of how much this is something that belongs in its own library and is too heavy for the stdlib. A coherent, vaguely safe API for randomness is nontrivial, to say the least.

In fact, the strongest argument against it is that it’s just too easy for novices to shoot themselves in the foot with a builtin PRNG. Swift is supposed to make it *harder* to write broken unsafe code, not easier. And that’s not even considering that of the available OS-level functions only random_r() explicitly provides a thread-safety guarantee (so it’s even *easier* for users to mess themselves up without even realizing it, especially with libdispatch being so awesome in Swift 3).

Swift shouldn't promote the use of RNGs by users who don't understand their pitfalls, and adding it to the stdlib does just that. At least forcing users to explicitly call into C APIs, or find existing libraries which have hopefully already focused their time on these considerations, adds an extra step that will ideally lead them to be a bit more conservative - C is "hard mode" from Swift’s POV. (One could argue that it’ll instead encourage them to roll their own insecure implementations, but that’ll happen with or without a builtin API so why make it easier?)

-- Gwynne Raskind
More magic than a mere signature can contain

···

On Jul 3, 2016, at 13:27, Robert Widmann via swift-dev <swift-dev@swift.org> wrote:

Trouble is, most modern languages disagree with that and have chosen to split them out of their standard libraries.

- Rust GitHub - rust-random/rand: A Rust library for random number generation.
- Go rand package - math/rand - Go Packages
- Dart Random class - dart:math library - Dart API
- Elm GitHub - jcollard/elm-random: Seed based random numbers in Elm
- Haskell System.Random

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).

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.

~Robert Widmann

2016/07/03 5:37、James Andrews via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> のメッセージ:

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.

As to the implementation, would it not be foolish to stray to far from the already well proven, existing well understood PRNG implementations?

Thanks,
James

On 3 July 2016 at 07:46:16, Austin Zheng (austinzheng@gmail.com <mailto:austinzheng@gmail.com>) wrote:

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.

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.

Best,
Austin

> On Jul 2, 2016, at 11:30 PM, Brent Royal-Gordon via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>
>> On Jun 24, 2016, at 6:38 AM, James Andrews via swift-dev <swift-dev@swift.org <mailto: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 <mailto:swift-dev@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

Hi All,
  
Thanks a lot for the quality feedback. I think that not only answers my
question, but has also swayed me in the direction of not having Random()
in the standard library. At least for now.
  
My original thinking was along the lines of what you suggest in that
leaving it out might encourage people to build bad implementations. But
you're point is valid, people will probably do that anyway if they feel
so inclined.
  
Whilst I still think it might be a good building block and having a
solid PRNG in the stnd library may make sense down the road, it seems
there are so many good reasons to leave this up to another library. Its
clearly not as straight forward as my original thinking suggested.
Thanks very much for the detailed responses!

···

--
  James Andrews
  james@enigmanorth.com
  
On Mon, Jul 4, 2016, at 06:37 AM, Gwynne Raskind wrote:

C++11 defines PRNGs in the STL, but even then the API is fairly
complex thanks to the need for so many different options for source,
distribution, seeds, security... - and it *still* doesn’t cover all of
what I consider the obvious cases (YMMV).

I agree with Robert here, Swift isn’t ready to have that heavy a
functionality be part of its core library. For that matter, I question
if it’s even a question of readiness so much as one of the API being
suitable to a stdlib at all! Having the basic tools available via
Darwin/Glibc and/or Foundation is plenty. If you have a need for
stronger guarantees in your entropy than you can get from the common
functions like rand, random, *rand48, arc4random, etc., it’s unlikely
that any stdlib-provided option is going to meet your needs anyway.

I mean, not that I don’t wish there was something like ***SSL’s RAND
functionality around, but that just underscores the heck out of how
much this is something that belongs in its own library and is too
heavy for the stdlib. A coherent, vaguely safe API for randomness is
nontrivial, to say the least.

In fact, the strongest argument against it is that it’s just too easy
for novices to shoot themselves in the foot with a builtin PRNG. Swift
is supposed to make it *harder* to write broken unsafe code, not
easier. And that’s not even considering that of the available OS-level
functions only random_r() explicitly provides a thread-safety
guarantee (so it’s even *easier* for users to mess themselves up
without even realizing it, especially with libdispatch being so
awesome in Swift 3).

Swift shouldn't promote the use of RNGs by users who don't understand
their pitfalls, and adding it to the stdlib does just that. At least
forcing users to explicitly call into C APIs, or find existing
libraries which have hopefully already focused their time on these
considerations, adds an extra step that will ideally lead them to be a
bit more conservative - C is "hard mode" from Swift’s POV. (One could
argue that it’ll instead encourage them to roll their own insecure
implementations, but that’ll happen with or without a builtin API so
why make it easier?)

-- Gwynne Raskind
More magic than a mere signature can contain

On Jul 3, 2016, at 13:27, Robert Widmann via swift-dev <swift- >> dev@swift.org> wrote:

Trouble is, most modern languages disagree with that and have chosen
to split them out of their standard libraries.

- Rust GitHub - rust-random/rand: A Rust library for random number generation.
- Go rand package - math/rand - Go Packages
- Dart
  Random class - dart:math library - Dart API
- Elm GitHub - jcollard/elm-random: Seed based random numbers in Elm
- Haskell
  System.Random

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).

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.

~Robert Widmann

2016/07/03 5:37、James Andrews via swift-dev <swift-dev@swift.org>
のメッセージ:

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.

As to the implementation, would it not be foolish to stray to far
from the already well proven, existing well understood PRNG
implementations?

Thanks,
James

On 3 July 2016 at 07:46:16, Austin Zheng (austinzheng@gmail.com) >>> wrote:

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. >>>> >>>> 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. >>>>
>>>> Best, >>>> Austin >>>> >>>> > On Jul 2, 2016, at 11:30 PM,
Brent Royal-Gordon via swift-dev <swift-dev@swift.org> wrote: >>>>
> >>>> >> 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

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev