[Proposal] Random Unification

xwu · November 6, 2017, 12:07am

A few quick thoughts:

I know that there's been some discussion that `(1...10).random` is the best
spelling, but I'd like to push back on that suggestion. When I want a
random number, I tend to think of the type I want first ("I want a random
integer") and then a range ("I want a random integer between a and b"), not
the other way around. My intuition is that `Int.random(in:)` will be more
discoverable, both on that basis and because it is more similar to other
languages' syntax (`Math.random` in JavaScript and `randint` in NumPy, for
example). It also has the advantage that the type is explicit, which I
think is particularly useful in this case because the value itself is,
well, random.

I would also argue that, `random` is most appropriately a method and not a
property; there's no hard and fast rule for this, but the fact that the
result is stochastic suggests (to me) that it's not a "property" of the
range (or, for that matter, of the type).

I would reiterate here my qualms about `Source` being the term used for a
generator. These types are not a _source_ of entropy but rather a
_consumer_ of entropy.

`UnsafeRandomSource` needs to be renamed; "unsafe" has a specific meaning
in Swift--that is, memory safety, and this is not it. Moreover, it's
questionable whether this protocol is useful in any sense. What useful
generic algorithms can one write with such a protocol?

`XoroshiroRandom` cannot be seeded by any `Numeric` value; depending on the
specific algorithm it needs a seed of a specific bit width. If you default
the shared instance to being seeded with an `Int` then you will have to
have distinct implementations for 32-bit and 64-bit platforms. This is
unadvisable. On that note, your `UnsafeRandomSource` needs to have an
associated type and not a generic `<T : Numeric>` for the seed.

The default random number generator should be cryptographically secure;
however, it's not clear to me that it should be device random.

I agree with others that alternative random number generators other than
the default RNG (and, if not default, possibly also the device RNG) should
be accommodated by the protocol hierarchy but not necessarily supplied in
the stdlib.

The term `Randomizable` means something specific which is not how it's used
in your proposed protocol.

There's still the open question, not answered, about how requesting an
instance of the hardware RNG behaves when there's insufficient or no
entropy. Does it return nil, throw, trap, or wait? The proposed API does
not clarify this point, although based on the method signature it cannot
return nil or throw. Trapping might be acceptable but I'd be interested to
hear your take as to why it is preferable.

···

On Sun, Nov 5, 2017 at 4:43 PM, Alejandro Alonso via swift-evolution < swift-evolution@swift.org> wrote:

For the proof of concept, I had accidentally deleted that one. I have a
more up to date one which was discussed a few weeks later.
Swift Random Unification Design · GitHub

- Alejandro

On Nov 5, 2017, 4:37 PM -0600, Jonathan Hull <jhull@gbis.com>, wrote:

Is there a link to the writeup? The one in the quote 404s.

Thanks,
Jon

On Nov 5, 2017, at 2:10 PM, Alejandro Alonso via swift-evolution < > swift-evolution@swift.org> wrote:

Hello once again Swift evolution community. I have taken the time to write
up the proposal for this thread, and have provided an implementation for it
as well. I hope to once again get good feedback on the overall proposal.

- Alejandro

On Sep 8, 2017, 11:52 AM -0500, Alejandro Alonso via swift-evolution < > swift-evolution@swift.org>, wrote:

Hello swift evolution, I would like to propose a unified approach to
`random()` in Swift. I have a simple implementation here
https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5\. This
implementation is a simple wrapper over existing random functions so
existing code bases will not be affected. Also, this approach introduces a
new random feature for Linux users that give them access to upper bounds,
as well as a lower bound for both Glibc and Darwin users. This change would
be implemented within Foundation.

I believe this simple change could have a very positive impact on new
developers learning Swift and experienced developers being able to write
single random declarations.

I’d like to hear about your ideas on this proposal, or any implementation
changes if need be.

- Alejando

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

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

Alejandro · November 6, 2017, 12:12am

The proposal and implementation have the current updated API. The link I sent Jon was the one I brought up a few weeks ago which is outdated now. The proposal answers all of your questions. As for `.random` being a function, some would argue that it behaves in the same way as `.first` and `.last` which are properties.

- Alejandro

···

On Nov 5, 2017, 6:07 PM -0600, Xiaodi Wu <xiaodi.wu@gmail.com>, wrote:
A few quick thoughts:

I know that there's been some discussion that `(1...10).random` is the best spelling, but I'd like to push back on that suggestion. When I want a random number, I tend to think of the type I want first ("I want a random integer") and then a range ("I want a random integer between a and b"), not the other way around. My intuition is that `Int.random(in:)` will be more discoverable, both on that basis and because it is more similar to other languages' syntax (`Math.random` in JavaScript and `randint` in NumPy, for example). It also has the advantage that the type is explicit, which I think is particularly useful in this case because the value itself is, well, random.

I would also argue that, `random` is most appropriately a method and not a property; there's no hard and fast rule for this, but the fact that the result is stochastic suggests (to me) that it's not a "property" of the range (or, for that matter, of the type).

I would reiterate here my qualms about `Source` being the term used for a generator. These types are not a _source_ of entropy but rather a _consumer_ of entropy.

`UnsafeRandomSource` needs to be renamed; "unsafe" has a specific meaning in Swift--that is, memory safety, and this is not it. Moreover, it's questionable whether this protocol is useful in any sense. What useful generic algorithms can one write with such a protocol?

`XoroshiroRandom` cannot be seeded by any `Numeric` value; depending on the specific algorithm it needs a seed of a specific bit width. If you default the shared instance to being seeded with an `Int` then you will have to have distinct implementations for 32-bit and 64-bit platforms. This is unadvisable. On that note, your `UnsafeRandomSource` needs to have an associated type and not a generic `<T : Numeric>` for the seed.

The default random number generator should be cryptographically secure; however, it's not clear to me that it should be device random.

I agree with others that alternative random number generators other than the default RNG (and, if not default, possibly also the device RNG) should be accommodated by the protocol hierarchy but not necessarily supplied in the stdlib.

The term `Randomizable` means something specific which is not how it's used in your proposed protocol.

There's still the open question, not answered, about how requesting an instance of the hardware RNG behaves when there's insufficient or no entropy. Does it return nil, throw, trap, or wait? The proposed API does not clarify this point, although based on the method signature it cannot return nil or throw. Trapping might be acceptable but I'd be interested to hear your take as to why it is preferable.

On Sun, Nov 5, 2017 at 4:43 PM, Alejandro Alonso via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote:
For the proof of concept, I had accidentally deleted that one. I have a more up to date one which was discussed a few weeks later. Swift Random Unification Design · GitHub

- Alejandro

On Nov 5, 2017, 4:37 PM -0600, Jonathan Hull <jhull@gbis.com<mailto:jhull@gbis.com>>, wrote:
Is there a link to the writeup? The one in the quote 404s.

Thanks,
Jon

On Nov 5, 2017, at 2:10 PM, Alejandro Alonso via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote:

Hello once again Swift evolution community. I have taken the time to write up the proposal for this thread, and have provided an implementation for it as well. I hope to once again get good feedback on the overall proposal.

- Alejandro

On Sep 8, 2017, 11:52 AM -0500, Alejandro Alonso via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>>, wrote:
Hello swift evolution, I would like to propose a unified approach to `random()` in Swift. I have a simple implementation here https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5\. This implementation is a simple wrapper over existing random functions so existing code bases will not be affected. Also, this approach introduces a new random feature for Linux users that give them access to upper bounds, as well as a lower bound for both Glibc and Darwin users. This change would be implemented within Foundation.

I believe this simple change could have a very positive impact on new developers learning Swift and experienced developers being able to write single random declarations.

I’d like to hear about your ideas on this proposal, or any implementation changes if need be.

- Alejando

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

xwu · January 2, 2018, 6:29pm

Just skimmed through the updated proposal and am weighing in with my naïve
opinions:

   - I’m still highly skeptical of a static “T.random” API. I’ve yet to
   see a convincing example where it’d be useful to pick a value from the
   range of all possible values. The only truly useful one I’ve seen is “pick
   a random bool”, which could easily be done via “[true, false].random()"

   - I much prefer the GameplayKit API[0], which breaks the idea of
   randomness up in to 2 separate concepts:
      - A “Source” → Where the random numbers come from
      - A “Distribution” → Initialized with a source, it makes sure the
      produced numbers exhibit a specific distribution over multiple samplings.
      Ie, a uniform distribution vs a Gaussian distribution, or something like “I
      want to pick a card from a deck but bias choices towards Spades or Aces”.
      I’m also reminded of the anecdote of how iTunes had to modify their
      “playlist shuffle” algorithm to be less random[1], because the true
      randomness would do weird things that made it seem not random. Spotify had
      the same problem and solution[2].
      - Breaking things up like this would also make it easier to test
      randomness (by using a replay-able source) but that still follow the
      parameters of your app (that it has a bell-curve distribution of
      probabilities, for example)

      - I’d still really really really like to see how this could be done
   as two separate things:
      - A minimal implementation in the Standard Library (like, defining
      the base Source and Distribution protocols, with a single default
      implementation of each)
      - A proposal for a more complete “non-standard library” where the
      larger array of functionality would be contained. For example, IMO I don’t
      think the shuffling stuff needs to be in the standard library. This is also
      where all the cryptographically secure stuff (that your typical app
      developer does not need) would live.

      - The “random” element of a collection/range should be “func
   random() → Element?”, not “var random: Element?”. Property values shouldn't
   change between accesses. Ditto the static “Randomizable.random” property.

   - What do you think about actively discouraging people from using the
   modulo operator to create a range? It could be done by having the RNGs
   return a “RandomValue<T>” type, then defining a mod operator that takes a
   RandomValue<T> and a T (?), and then giving it a deprecation warning +
   fixit. Not sure if that’d be worth the type overhead, but I’m very much in
   favor of encouraging people towards better practices.

   - I’m +1 on crashing if we can’t produce a random number.

   - What do you think about the philosophical difference of
   Type.random(using:) vs Type.init(randomSource:)?

Dave

[0]: GKRandom | Apple Developer Documentation
[1]: https://www.youtube.com/watch?v=lg188Ebas9E&feature=youtu.be&t=719
[2]: https://labs.spotify.com/2014/02/28/how-to-shuffle-songs/

I think these are some excellent points. Earlier, I think, others also
emphasized this idea of exploring what a really minimal implementation in
the standard library would look like, and I've been thinking about this
overnight.

There is much that is commendable about Alejandro's proposal, but I agree
that there is more than needs to be in the standard library. Here's what I
think the shape of a minimal API would look like, which would
simultaneously enable others to implement their desired functionality as an
end user:

- We need very performant, but otherwise barebones, access to system
randomness so that it can be a building block for everything else. Because
this is so special in that it cannot be seeded or initialized, unlike other
RNGs, we don't need this to be a type, and it doesn't need to conform to a
`RandomNumberGenerator` protocol. It can be as straightforward as one or
both of:

-- A global `func random() -> UInt32`, which is essentially `arc4random` on
macOS/iOS and reads from an appropriate secure source on Linux and other
platforms. One pro of having such a method is that it's a drop-in
replacement for `arc4random()` that's _very_ convenient as a primitive to
build up other random operations; one con is that it encourages modulo
bias, although fortunately mostly only with UInt32.
-- An extension method on `UnsafeMutableRawBufferPointer` named `func
copyRandomBytes()`. This would look a lot like Apple's `SecCopyRandomBytes`
and BSD's `arc4random_buf`.

- Having established the primitive, then we can ask what is the minimum
_useful_ functionality for an end user. I think the answer is a very
judicious subset of the currently proposed functionality:

-- An extension method or property (`random()` or `random`) on
`RandomAccessCollection`.
-- An extension method or property (`random()` or `random`) on `Range where
Bound : SignedInteger`, `Range where Bound : UnsignedInteger`, `Range where
Bound : BinaryFloatingPoint`.

- One advantage of abandoning `Randomizable` and spellings like
`Int.random` and `Double.random` is limiting possible modulo bias in using
the former, and also eliminating the lack of semantic guarantees about the
implicit bounds (which for Int are Int.min...Int.max, but for Double must
be 0..<1). There can be no confusion about `(0.0..<1.0).random`.
- An advantage inherent to abandoning the `randomIn:` or `random(in:)`
spelling is that users must now explicitly address what to do about an
empty range, which in my view is better than an implicit trap that may or
may not happen deterministically during testing.
- A final advantage over the current proposal is that we collapse three
very similar spellings with subtle usage differences but entirely
overlapping functionality--`Int.random`, `Int.random(in:)`, and
`Range.random`--into one with well-defined semantics. A user learns once
and can have good understanding of others' code and write their own without
hidden pitfalls.

The end result of such a minimalist design is that we introduce no new
types, no new protocols, and only three or four new functions. They all
have very defined semantics, and together they enable both basic use and
provide the building blocks for advanced users to create their own PRNGs
that fit their advanced cryptographic or non-cryptographic needs.

Thoughts?

···

On Tue, Jan 2, 2018 at 10:19 AM, Dave DeLong via swift-evolution < swift-evolution@swift.org> wrote:

On Jan 2, 2018, at 1:35 AM, Alejandro Alonso via swift-evolution < > swift-evolution@swift.org> wrote:

Hello swift evolution once again, I’ve been hard at work considering every
email and revising the proposal. I’ve made lots of changes and additions to
the proposal to discuss some problems we’ve had (T.random), and walks
through detailed design. You can see the proposal here:
[Proposal] Random Unification by Azoy · Pull Request #760 · apple/swift-evolution · GitHub .

A big issue that lots of people pointed out was `T.random %` and to remove
it completely from the API. To give a gist of why I continue to support
T.random:

1. Modulo bias misuse is only a problem to types that conform to
`BinaryInteger`. Why remove this functionality if only a portion of the
types have the ability of misuse. `Double.random % 10` is a good example of
where modulo isn’t implemented here as it produces the error, “'%' is
unavailable: Use truncatingRemainder instead”.

2. `Int.random(in: Int.min … Int.max)` doesn’t work. For developers that
actually rely on this functionality, the work around that was discussed
earlier simply doesn’t work. `Int.min … Int.max`’s count property exceeds
that of `Int`’s numerical range. A working work around would be something
along the lines of `Int(truncatingIfNeeded: Random.default.next(UInt.self))`
which creates a pain point for those developers. As the goal of this
proposal to remove pain points regarding random, this change does the
opposite.

I’m interested to hear if anymore discussion around this, or any other
issues come up.

- Alejandro

On Sep 8, 2017, 11:52 AM -0500, Alejandro Alonso via swift-evolution < > swift-evolution@swift.org>, wrote:

Hello swift evolution, I would like to propose a unified approach to
`random()` in Swift. I have a simple implementation here
https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5\. This
implementation is a simple wrapper over existing random functions so
existing code bases will not be affected. Also, this approach introduces a
new random feature for Linux users that give them access to upper bounds,
as well as a lower bound for both Glibc and Darwin users. This change would
be implemented within Foundation.

I believe this simple change could have a very positive impact on new
developers learning Swift and experienced developers being able to write
single random declarations.

I’d like to hear about your ideas on this proposal, or any implementation
changes if need be.

- Alejando

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

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

fclout · January 2, 2018, 6:17pm

I'm not sure how much background you have into this thread, but the idea of sources and distributions was rejected months ago as almost always too cumbersome given that people overwhelmingly want uniform random numbers.

I agree that random() is better as a method. I also think that the default Random implementation should be in a class, not a struct. If a generator has value semantics, I would expect that two copies would return an identical sequence of numbers.

I think that it'll be hard to make a RandomValue<T> that nicely converts to T. The best way to discourage modulo is probably to make T.random/T(randomSource:) as cumbersome as possible, and Range.random as nice as possible.

···

Le 2 janv. 2018 à 11:19, Dave DeLong via swift-evolution <swift-evolution@swift.org> a écrit :

Just skimmed through the updated proposal and am weighing in with my naïve opinions:

I’m still highly skeptical of a static “T.random” API. I’ve yet to see a convincing example where it’d be useful to pick a value from the range of all possible values. The only truly useful one I’ve seen is “pick a random bool”, which could easily be done via “[true, false].random()"

I much prefer the GameplayKit API[0], which breaks the idea of randomness up in to 2 separate concepts:
A “Source” → Where the random numbers come from
A “Distribution” → Initialized with a source, it makes sure the produced numbers exhibit a specific distribution over multiple samplings. Ie, a uniform distribution vs a Gaussian distribution, or something like “I want to pick a card from a deck but bias choices towards Spades or Aces”. I’m also reminded of the anecdote of how iTunes had to modify their “playlist shuffle” algorithm to be less random[1], because the true randomness would do weird things that made it seem not random. Spotify had the same problem and solution[2].
Breaking things up like this would also make it easier to test randomness (by using a replay-able source) but that still follow the parameters of your app (that it has a bell-curve distribution of probabilities, for example)

I’d still really really really like to see how this could be done as two separate things:
A minimal implementation in the Standard Library (like, defining the base Source and Distribution protocols, with a single default implementation of each)
A proposal for a more complete “non-standard library” where the larger array of functionality would be contained. For example, IMO I don’t think the shuffling stuff needs to be in the standard library. This is also where all the cryptographically secure stuff (that your typical app developer does not need) would live.

The “random” element of a collection/range should be “func random() → Element?”, not “var random: Element?”. Property values shouldn't change between accesses. Ditto the static “Randomizable.random” property.

What do you think about actively discouraging people from using the modulo operator to create a range? It could be done by having the RNGs return a “RandomValue<T>” type, then defining a mod operator that takes a RandomValue<T> and a T (?), and then giving it a deprecation warning + fixit. Not sure if that’d be worth the type overhead, but I’m very much in favor of encouraging people towards better practices.

I’m +1 on crashing if we can’t produce a random number.

What do you think about the philosophical difference of Type.random(using:) vs Type.init(randomSource:)?

Dave

[0]: GKRandom | Apple Developer Documentation
[1]: https://www.youtube.com/watch?v=lg188Ebas9E&feature=youtu.be&t=719 <https://www.youtube.com/watch?v=lg188Ebas9E&feature=youtu.be&t=719>
[2]: https://labs.spotify.com/2014/02/28/how-to-shuffle-songs/

On Jan 2, 2018, at 1:35 AM, Alejandro Alonso via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello swift evolution once again, I’ve been hard at work considering every email and revising the proposal. I’ve made lots of changes and additions to the proposal to discuss some problems we’ve had (T.random), and walks through detailed design. You can see the proposal here: [Proposal] Random Unification by Azoy · Pull Request #760 · apple/swift-evolution · GitHub .

A big issue that lots of people pointed out was `T.random %` and to remove it completely from the API. To give a gist of why I continue to support T.random:

1. Modulo bias misuse is only a problem to types that conform to `BinaryInteger`. Why remove this functionality if only a portion of the types have the ability of misuse. `Double.random % 10` is a good example of where modulo isn’t implemented here as it produces the error, “'%' is unavailable: Use truncatingRemainder instead”.

2. `Int.random(in: Int.min … Int.max)` doesn’t work. For developers that actually rely on this functionality, the work around that was discussed earlier simply doesn’t work. `Int.min … Int.max`’s count property exceeds that of `Int`’s numerical range. A working work around would be something along the lines of `Int(truncatingIfNeeded: Random.default.next(UInt.self))` which creates a pain point for those developers. As the goal of this proposal to remove pain points regarding random, this change does the opposite.

I’m interested to hear if anymore discussion around this, or any other issues come up.

- Alejandro

On Sep 8, 2017, 11:52 AM -0500, Alejandro Alonso via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>, wrote:

Hello swift evolution, I would like to propose a unified approach to `random()` in Swift. I have a simple implementation here https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5\. This implementation is a simple wrapper over existing random functions so existing code bases will not be affected. Also, this approach introduces a new random feature for Linux users that give them access to upper bounds, as well as a lower bound for both Glibc and Darwin users. This change would be implemented within Foundation.

I believe this simple change could have a very positive impact on new developers learning Swift and experienced developers being able to write single random declarations.

I’d like to hear about your ideas on this proposal, or any implementation changes if need be.

- Alejando

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

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

Brent_Royal-Gordon · September 9, 2017, 10:19pm

Software engineers are *so* bad at this.

···

On Sep 9, 2017, at 12:03 PM, Taylor Swift via swift-evolution <swift-evolution@swift.org> wrote:

I would argue that anyone doing cryptography probably already knows how important RNG selection is and can be expected to look for a specialized cryptographically secure RNG. I doubt they would just use the default RNG without first checking the documentation.

--
Brent Royal-Gordon
Architechies

Jean-Daniel1 · September 9, 2017, 10:14pm

If it where the case, why is there so many security issues due to poor choice of random source ?

···

Le 9 sept. 2017 à 21:03, Taylor Swift via swift-evolution <swift-evolution@swift.org> a écrit :

On Fri, Sep 8, 2017 at 8:07 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Fri, Sep 8, 2017 at 7:50 PM, Stephen Canon <scanon@apple.com <mailto:scanon@apple.com>> wrote:

On Sep 8, 2017, at 8:09 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This topic has been broached on Swift Evolution previously. It's interesting to me that Steve Canon is so certain that CSPRNGs are the way to go. I wasn't aware that hardware CSPRNGs have come such a long way and are so ubiquitous as to be feasible as a basis for Swift random numbers. If so, great.

Otherwise, if there is any way that a software, non-cryptographically secure PRNG is going to outperform a CSPRNG, then I think it's worthwhile to have a (carefully documented) choice between the two. I would imagine that for many uses, such as an animation in which you need a plausible source of noise to render a flame, whether that is cryptographically secure or not is absolutely irrelevant but performance may be key.

Let me be precise: it is absolutely possible to outperform CSPRNGs. They have simply become fast enough that the performance gap doesn’t matter for most uses (let’s say amortized ten cycles per byte or less—whatever you are going to do with the random bitstream will be much more expensive than getting the bits was).

That said, yes, there should definitely be other options. It should be possible for users to get reproducible results from a stdlib random interface run-to-run, and also across platforms. That alone requires that at least one other option for a generator be present. There may also be a place for a very high-throughput generator like xorshiro128+.

All I’m really saying is that the *default* generator should be an os-provided unseeded CSPRNG, and we should be very careful about documenting any generator options.

Agree on all points. Much like Swift's strings are Unicode-correct instead of the fastest possible way of slicing and dicing sequences of ASCII characters, Swift's default PRNG should be cryptographically secure.

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

I would argue that anyone doing cryptography probably already knows how important RNG selection is

fclout · September 26, 2017, 4:26pm

* The distinction to be made here is CSPRNGs versus non-cryptographically secure PRNGs, where CSPRNG : PRNG. “Reproducible” is not the right word. Based on my understanding, some CSPRNGs can be “reproducible” if the seed is known; what makes it cryptographically secure is that observing its previous *outputs* does not provide information useful to predict future outputs. Along those lines, it may be important to securely delete the seed from memory as soon as possible; there is some way of doing so in C (it’s used in the ChaCha20 reference implementation) but I don’t believe any way of doing so in Swift.

It's possible to use a CSPRNG-grade algorithm and seed it once to get a reproducible sequence, but when you use it as a CSPRNG, you typically feed entropy back into it at nondeterministic points to ensure that even if you started with a bad seed, you'll eventually get to an alright state. Unless you keep track of when entropy was mixed in and what the values were, you'll never get a reproducible CSPRNG.

We would give developers a false sense of security if we provided them with CSPRNG-grade algorithms that we called CSPRNGs and that they could seed themselves. Just because it says "crypto-secure" in the name doesn't mean that it'll be crypto-secure if it's seeded with time(). Therefore, "reproducible" vs "non-reproducible" looks like a good distinction to me.

* On the issue of consuming entropy: a glaring underlying inconvenience in the API needs to be reckoned with. Sometimes, there simply isn’t enough entropy to generate another random number. If cryptographic security were not default, then it might be OK to fall back to some other method that produces a low-quality result. However, if we are to do the secure thing, we must decide whether the lack of entropy results in a call to a random method to (a) return nil; (b) throw; (c) fatalError; or (d) block. There is no way to paper over this problem; not enough entropy means you can’t get a random number when you want it. The debate over blocking versus non-blocking error, for example, held up the addition of getrandom() to Glibc for some time. In my proposed design, initializing a PRNG from the system’s secure stream of random bytes is failable; therefore, a user can choose how to handle the lack of entropy. However, it is desirable to have a thread-local CSPRNG that is used for calls, say, to Int.random(). It would be unfortunate if Int.random() itself was failable; however, that leads to an uncomfortable question: if there is insufficient entropy, should Int.random() block or fatalError? That seems pretty terrible too. However, one cannot simply write this off as an edge case: if this is to be a robust part of the standard library, it must do the “right” thing. Particularly if Swift is to be a true systems programming language and it must accommodate the case when a system is first booted and there is very little entropy.

That's not really the case anymore these days. You're probably thinking of /dev/urandom vs. /dev/random. On Darwin, they're the same thing and never run out (see man urandom). On Linux, the state of the art is that you leave /dev/random alone. Don't take it from me, Prof. Daniel J. Bernstein <https://en.wikipedia.org/wiki/Daniel_J._Bernstein> wrote this <https://www.mail-archive.com/cryptography@randombit.net/msg04763.html> a while ago:

Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that

(1) we can't figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom), but

(2) we _can_ figure out how to use a single key to safely encrypt many messages (this is what we need from SSL, PGP, etc.).

For a cryptographer this doesn't even pass the laugh test.

So that shouldn't be too concerning.

* What should the default CSPRNG be? There are good arguments for using a cryptographically secure device random. (In my proposed implementation, for device random, I use Security.framework on Apple platforms (because /dev/urandom is not guaranteed to be available due to the sandbox, IIUC). On Linux platforms, I would prefer to use getrandom() and avoid using file system APIs, but getrandom() is new and unsupported on some versions of Ubuntu that Swift supports. This is an issue in and of itself.) Now, a number of these facilities strictly limit or do not guarantee availability of more than a small number of random bytes at a time; they are recommended for seeding other PRNGs but *not* as a routine source of random numbers. Therefore, although device random should be available to users, it probably shouldn’t be the default for the Swift standard library as it could have negative consequences for the system as a whole. There follows the significant task of implementing a CSPRNG correctly and securely for the default PRNG.

Theo give a talk a few years ago <https://www.youtube.com/watch?v=aWmLWx8ut20> on randomness and how these problems are approached in LibreSSL.

Félix

···

Le 26 sept. 2017 à 07:31, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> a écrit :

xwu · September 26, 2017, 11:14pm

* The distinction to be made here is CSPRNGs versus non-cryptographically
secure PRNGs, where CSPRNG : PRNG. “Reproducible” is not the right word.
Based on my understanding, some CSPRNGs can be “reproducible” if the seed
is known; what makes it cryptographically secure is that observing its
previous *outputs* does not provide information useful to predict future
outputs. Along those lines, it may be important to securely delete the seed
from memory as soon as possible; there is some way of doing so in C (it’s
used in the ChaCha20 reference implementation) but I don’t believe any way
of doing so in Swift.

It's possible to use a CSPRNG-grade algorithm and seed it once to get a
reproducible sequence, but when you use it as a CSPRNG, you typically feed
entropy back into it at nondeterministic points to ensure that even if you
started with a bad seed, you'll eventually get to an alright state. Unless
you keep track of when entropy was mixed in and what the values were,
you'll never get a reproducible CSPRNG.

We would give developers a false sense of security if we provided them
with CSPRNG-grade algorithms that we called CSPRNGs and that they could
seed themselves. Just because it says "crypto-secure" in the name doesn't
mean that it'll be crypto-secure if it's seeded with time(). Therefore,
"reproducible" vs "non-reproducible" looks like a good distinction to me.

I disagree here, in two respects:

First, whether or not a particular PRNG is cryptographically secure is an
intrinsic property of the algorithm; whether it's "reproducible" or not is
determined by the published API. In other words, the distinction between
CSPRNG vs. non-CSPRNG is important to document because it's semantics that
cannot be deduced by the user otherwise, and it is an important one for
writing secure code because it tells you whether an attacker can predict
future outputs based only on observing past outputs. "Reproducible" in the
sense of seedable or not is trivially noted by inspection of the published
API, and it is rather immaterial to writing secure code. If your attacker
can observe your seeding once, chances are that they can observe your
reseeding too; then, they can use their own implementation of the PRNG
(whether CSPRNG or non-CSPRNG) and reproduce your pseudorandom sequence
whether or not Swift exposes any particular API.

Secondly, I see no reason to justify the notion that, simply because a PRNG
is cryptographically secure, we ought to hide the seeding initializer
(because one has to exist internally anyway) from the public. Obviously,
one use case for a deterministic PRNG is to get reproducible sequences of
random-appearing values; this can be useful whether the underlying
algorithm is cryptographically secure or not. There are innumerably many
ways to use data generated from a CSPRNG in non-cryptographically secure
ways and omitting or including a public seeding initializer does not change
that; in other words, using a deterministic seed for a CSPRNG would be a
bad idea in certain applications, but it's a deliberate act, and someone
who would mistakenly do that is clearly incapable of *using* the output
from the PRNG in a secure way either; put a third way, you would be hard
pressed to find a situation where it's true that "if only Swift had not
made the seeding initializer public, this author would have written secure
code, but instead the only security hole that existed in the code was
caused by the availability of a public seeding initializer mistakenly
used." The point of having both explicitly instantiable PRNGs and a layer
of simpler APIs like "Int.random()" is so that the less experienced user
can get the "right thing" by default, and the experienced user can
customize the behavior; any user that instantiates his or her own
ChaCha20Random instance is already calling for the power user interface; it
is reasonable to expose the underlying primitive operations (such as
seeding) so long as there are legitimate uses for it.

* On the issue of consuming entropy: a glaring underlying inconvenience in
the API needs to be reckoned with. Sometimes, there simply isn’t enough
entropy to generate another random number. If cryptographic security were
not default, then it might be OK to fall back to some other method that
produces a low-quality result. However, if we are to do the secure thing,
we must decide whether the lack of entropy results in a call to a random
method to (a) return nil; (b) throw; (c) fatalError; or (d) block. There is
no way to paper over this problem; not enough entropy means you can’t get a
random number when you want it. The debate over blocking versus
non-blocking error, for example, held up the addition of getrandom() to
Glibc for some time. In my proposed design, initializing a PRNG from the
system’s secure stream of random bytes is failable; therefore, a user can
choose how to handle the lack of entropy. However, it is desirable to have
a thread-local CSPRNG that is used for calls, say, to Int.random(). It
would be unfortunate if Int.random() itself was failable; however, that
leads to an uncomfortable question: if there is insufficient entropy,
should Int.random() block or fatalError? That seems pretty terrible too.
However, one cannot simply write this off as an edge case: if this is to be
a robust part of the standard library, it must do the “right” thing.
Particularly if Swift is to be a true systems programming language and it
must accommodate the case when a system is first booted and there is very
little entropy.

That's not really the case anymore these days. You're probably thinking of
/dev/urandom vs. /dev/random.

I'm also talking about getrandom() on Linux, getentropy() on BSD and Linux,
and SecCopyRandomBytes() on Apple platforms.

On Darwin, they're the same thing and never run out (see man urandom). On
Linux, the state of the art is that you leave /dev/random alone. Don't take
it from me, Prof. Daniel J. Bernstein
<https://en.wikipedia.org/wiki/Daniel_J._Bernstein> wrote this
<https://www.mail-archive.com/cryptography@randombit.net/msg04763.html> a
while ago:

Think about this for a moment: whoever wrote the /dev/random manual page
seems to simultaneously believe that

(1) we can't figure out how to deterministically expand one 256-bit
/dev/random output into an endless stream of unpredictable keys (this is
what we need from urandom), but

(2) we _can_ figure out how to use a single key to safely encrypt many
messages (this is what we need from SSL, PGP, etc.).

For a cryptographer this doesn't even pass the laugh test.

So that shouldn't be too concerning.

I'm fully aware of the myths surrounding /dev/urandom and /dev/random.
/dev/urandom might never run out, but it is also possible for it not to be
initialized at all, as in the case of some VM setups. In some older
versions of iOS, /dev/[u]random is reportedly sandboxed out. On systems
where it is available, it can also be deleted, since it is a file. The
point is, all of these scenarios cause an error during seeding of a CSPRNG.
The question is, how to proceed in the face of inability to access entropy.
We must do something, because we cannot therefore return a
cryptographically secure answer. Rare trapping on invocation of
Int.random() or permanently waiting for a never-to-be-initialized
/dev/urandom would be terrible to debug, but returning an optional or
throwing all the time would be verbose. How to design this API?

* What should the default CSPRNG be? There are good arguments for using a

cryptographically secure device random. (In my proposed implementation, for
device random, I use Security.framework on Apple platforms (because
/dev/urandom is not guaranteed to be available due to the sandbox, IIUC).
On Linux platforms, I would prefer to use getrandom() and avoid using file
system APIs, but getrandom() is new and unsupported on some versions of
Ubuntu that Swift supports. This is an issue in and of itself.) Now, a
number of these facilities strictly limit or do not guarantee availability
of more than a small number of random bytes at a time; they are recommended
for seeding other PRNGs but *not* as a routine source of random numbers.
Therefore, although device random should be available to users, it probably
shouldn’t be the default for the Swift standard library as it could have
negative consequences for the system as a whole. There follows the
significant task of implementing a CSPRNG correctly and securely for the
default PRNG.

Theo give a talk a few years ago
<https://www.youtube.com/watch?v=aWmLWx8ut20> on randomness and how these
problems are approached in LibreSSL.

Certainly, we can learn a lot from those like Theo who've dealt with the
issue. I'm not in a position to watch the talk at the moment; can you
summarize what the tl;dr version of it is?

···

On Tue, Sep 26, 2017 at 11:26 AM, Félix Cloutier <felixcloutier@icloud.com> wrote:

Le 26 sept. 2017 à 07:31, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> a écrit :

Jon_Hull · September 27, 2017, 9:05am

Felix and Jonathan make some good points. Some general comments:

* I think, in general, this area needs a detailed review by those who are expert in the domain; especially if we are to assert that the design is cryptographically secure, we need to ensure that it is actually so. In other words, not just the algorithms that we intend to implement, but the implementations themselves. This is not at all trivial. We will also need to specify whether extension methods that generate certain distributions, etc., are guaranteed secure against side channel attacks where such implementations are known possible but more expensive.

* Without attempting to bikeshed, the use of the word “Source” is potentially confusing; it could suggest that the conforming type is a source of entropy when in fact it consumes entropy. In my proposed design, the protocol is simply named “PRNG” with an emphasis on the P (i.e. pseudorandom, not random).

This is a good point. My use of the word “source" in the code I shared (much) earlier is because I have a “Source” protocol which essentially represents an (effectively) infinite iterator/sequence. RandomSource is a specific sub-protocol I have which provides an infinite iterator/sequence for repeatably random numbers. There are other sources which take an array and cycle it’s indices, for example. I also have a constant source, which always returns the same thing. I use all of this to do cool generative graphical effects.

We would give developers a false sense of security if we provided them with CSPRNG-grade algorithms that we called CSPRNGs and that they could seed themselves. Just because it says "crypto-secure" in the name doesn't mean that it'll be crypto-secure if it's seeded with time(). Therefore, "reproducible" vs "non-reproducible" looks like a good distinction to me.

I disagree here, in two respects:

First, whether or not a particular PRNG is cryptographically secure is an intrinsic property of the algorithm; whether it's "reproducible" or not is determined by the published API. In other words, the distinction between CSPRNG vs. non-CSPRNG is important to document because it's semantics that cannot be deduced by the user otherwise, and it is an important one for writing secure code because it tells you whether an attacker can predict future outputs based only on observing past outputs. "Reproducible" in the sense of seedable or not is trivially noted by inspection of the published API, and it is rather immaterial to writing secure code. If your attacker can observe your seeding once, chances are that they can observe your reseeding too; then, they can use their own implementation of the PRNG (whether CSPRNG or non-CSPRNG) and reproduce your pseudorandom sequence whether or not Swift exposes any particular API.

Secondly, I see no reason to justify the notion that, simply because a PRNG is cryptographically secure, we ought to hide the seeding initializer (because one has to exist internally anyway) from the public.

To me, ReproducibleRandomSource has a semantic meaning (more than being a bag of methods). It has an init(seed:) method because you HAVE to be able to seed it for reproducibility (not because sources which have a seed would all be reproducible). The fact that RandomSource does not have that requirement doesn’t mean you can’t have a source which is seeded… it just allows for sources which aren’t. If something calls itself Reproducible, it should actually be reproducible, which includes being able to restore previous states (not just the starting seed).

* The distinction to be made here is CSPRNGs versus non-cryptographically secure PRNGs, where CSPRNG : PRNG. “Reproducible” is not the right word. Based on my understanding, some CSPRNGs can be “reproducible” if the seed is known; what makes it cryptographically secure is that observing its previous *outputs* does not provide information useful to predict future outputs. Along those lines, it may be important to securely delete the seed from memory as soon as possible; there is some way of doing so in C (it’s used in the ChaCha20 reference implementation) but I don’t believe any way of doing so in Swift.

Is CSPRNG vs PRNG really an important distinction for the API? It is an important distinction when choosing a source, of course, but should that be reflected in our protocols? We should definitely make sure that our API does not prevent secure/CSPRNGs from working (e.g. not requiring a seed in the base API).

Reproducible, on the other hand, is a completely different use-case, which requires a different API because it is used differently. We also need to make sure our protocol design does not preclude or make difficult these uses. (We just want to avoid people using them while thinking they are secure).

We should default to something reasonably secure, but also fast. People who are doing cryptography should be using a cryptography package… but that package should be able to plug seamlessly into whatever API we have created.

I am leaning towards a design with an abstract base protocol, and then sub-protocols for Reproducibility and Secureness.

* On the issue of consuming entropy: a glaring underlying inconvenience in the API needs to be reckoned with. Sometimes, there simply isn’t enough entropy to generate another random number. If cryptographic security were not default, then it might be OK to fall back to some other method that produces a low-quality result. However, if we are to do the secure thing, we must decide whether the lack of entropy results in a call to a random method to (a) return nil; (b) throw; (c) fatalError; or (d) block. There is no way to paper over this problem; not enough entropy means you can’t get a random number when you want it. The debate over blocking versus non-blocking error, for example, held up the addition of getrandom() to Glibc for some time. In my proposed design, initializing a PRNG from the system’s secure stream of random bytes is failable; therefore, a user can choose how to handle the lack of entropy. However, it is desirable to have a thread-local CSPRNG that is used for calls, say, to Int.random(). It would be unfortunate if Int.random() itself was failable; however, that leads to an uncomfortable question: if there is insufficient entropy, should Int.random() block or fatalError? That seems pretty terrible too. However, one cannot simply write this off as an edge case: if this is to be a robust part of the standard library, it must do the “right” thing. Particularly if Swift is to be a true systems programming language and it must accommodate the case when a system is first booted and there is very little entropy.

Agreed. I have an API (for non-cryptographic use) that has two methods of getting unique random objects. One is failable, and returns nil if the object can’t be shown to be unique. The other tries to get a unique object, but will give repeats if necessary… it always returns a thing.

We could do something similar with entropy. We could have either an optional or throwing function which returns our random number. A sub-protocol could define a version (with a different name) that is non-optional which will always return an answer, even at the risk of being less secure.

Thanks,
Jon

···

On Sep 26, 2017, at 7:31 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

ben-cohen · October 4, 2017, 11:26pm

- I’d love to see several of the most common random kinds supported, and I agree it would be nice (but not required IMO) for the default to be cryptographically secure.

I would be very careful about choosing a "simple" solution. There is a log, sad history of languages trying to provide a "simple" random number generator and accidentally providing a powerful footgun instead. But:

- We should avoid the temptation to nuke this mosquito with a heavy handed solution designed to solve all of the world’s problems: For example, the C++ random number stuff is crazily over-general. The stdlib should aim to solve (e.g.) the top 3 most common cases, and let a more specialized external library solve the fully general problem (e.g. seed management, every distribution imaginable, etc).

That's not to say we need to have seven engines and twenty distributions like C++ does. The standard library is not a statistics package; it exists to provide basic abstractions and fundamental functionality. I don't think it should worry itself with distributions at all. I think it needs to provide:

  1. The abstraction used to plug in different random number generators (i.e. an RNG protocol of some kind).

  2. APIs on existing standard library types which perform basic randomness-related functions correctly—essentially, encapsulating Knuth. (Specifically, I think selecting a random element from a collection (which also covers generating a random integer in a range), shuffling a mutable collection, and generating a random float will do the trick.)

  3. A default RNG with a conservative design that will sometimes be too slow, but will never be insufficiently random.

If you want to pick elements with a Poisson distribution, go get a statistics framework; if you want repeatable random numbers for testing, use a seedable PRNG from XCTest or some other test tools package. These can leverage the standard library's RNG protocol to work with existing random number generators or random number consumers.

+1 to this general plan!

This pretty much exactly matches my preferences.

If random numbers go into the std lib, they should being able to customize the source of randomness for speed or test reproducibility, but default to something sensible without the user having to know it’s configurable. On Darwin that default should be based on arc4random(3). The std lib doesn’t need to provide other non-default random sources. Non-random sources for testing should be part of test frameworks and plug in easily.

The proposal should include shuffle and random element from collection, which are much-requested and not really the controversial part so won't hold up the overall progress of the proposal.

(and no need for distributions other than uniform IMO, or otherwise)

···

On Sep 30, 2017, at 3:23 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Sep 11, 2017, at 9:43 PM, Brent Royal-Gordon <brent@architechies.com <mailto:brent@architechies.com>> wrote:

On Sep 9, 2017, at 10:31 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-Chris

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

xwu · November 6, 2017, 12:17am

My comments are directed to the "more up-to-date" document that you just
linked to in your reply to Jon. Is that one outdated? If so, can you send a
link to the updated proposal and implementation for which you're soliciting
feedback?

···

On Sun, Nov 5, 2017 at 6:12 PM, Alejandro Alonso <aalonso128@outlook.com> wrote:

The proposal and implementation have the current updated API. The link I
sent Jon was the one I brought up a few weeks ago which is outdated now.
The proposal answers all of your questions. As for `.random` being a
function, some would argue that it behaves in the same way as `.first` and
`.last` which are properties.

- Alejandro

On Nov 5, 2017, 6:07 PM -0600, Xiaodi Wu <xiaodi.wu@gmail.com>, wrote:

A few quick thoughts:

I know that there's been some discussion that `(1...10).random` is the
best spelling, but I'd like to push back on that suggestion. When I want a
random number, I tend to think of the type I want first ("I want a random
integer") and then a range ("I want a random integer between a and b"), not
the other way around. My intuition is that `Int.random(in:)` will be more
discoverable, both on that basis and because it is more similar to other
languages' syntax (`Math.random` in JavaScript and `randint` in NumPy, for
example). It also has the advantage that the type is explicit, which I
think is particularly useful in this case because the value itself is,
well, random.

I would also argue that, `random` is most appropriately a method and not a
property; there's no hard and fast rule for this, but the fact that the
result is stochastic suggests (to me) that it's not a "property" of the
range (or, for that matter, of the type).

I would reiterate here my qualms about `Source` being the term used for a
generator. These types are not a _source_ of entropy but rather a
_consumer_ of entropy.

`UnsafeRandomSource` needs to be renamed; "unsafe" has a specific meaning
in Swift--that is, memory safety, and this is not it. Moreover, it's
questionable whether this protocol is useful in any sense. What useful
generic algorithms can one write with such a protocol?

`XoroshiroRandom` cannot be seeded by any `Numeric` value; depending on
the specific algorithm it needs a seed of a specific bit width. If you
default the shared instance to being seeded with an `Int` then you will
have to have distinct implementations for 32-bit and 64-bit platforms. This
is unadvisable. On that note, your `UnsafeRandomSource` needs to have an
associated type and not a generic `<T : Numeric>` for the seed.

The default random number generator should be cryptographically secure;
however, it's not clear to me that it should be device random.

I agree with others that alternative random number generators other than
the default RNG (and, if not default, possibly also the device RNG) should
be accommodated by the protocol hierarchy but not necessarily supplied in
the stdlib.

The term `Randomizable` means something specific which is not how it's
used in your proposed protocol.

There's still the open question, not answered, about how requesting an
instance of the hardware RNG behaves when there's insufficient or no
entropy. Does it return nil, throw, trap, or wait? The proposed API does
not clarify this point, although based on the method signature it cannot
return nil or throw. Trapping might be acceptable but I'd be interested to
hear your take as to why it is preferable.

On Sun, Nov 5, 2017 at 4:43 PM, Alejandro Alonso via swift-evolution < > swift-evolution@swift.org> wrote:

For the proof of concept, I had accidentally deleted that one. I have a
more up to date one which was discussed a few weeks later.
Swift Random Unification Design · GitHub

- Alejandro

On Nov 5, 2017, 4:37 PM -0600, Jonathan Hull <jhull@gbis.com>, wrote:

Is there a link to the writeup? The one in the quote 404s.

Thanks,
Jon

On Nov 5, 2017, at 2:10 PM, Alejandro Alonso via swift-evolution < >> swift-evolution@swift.org> wrote:

Hello once again Swift evolution community. I have taken the time to
write up the proposal for this thread, and have provided an implementation
for it as well. I hope to once again get good feedback on the overall
proposal.

- Alejandro

On Sep 8, 2017, 11:52 AM -0500, Alejandro Alonso via swift-evolution < >> swift-evolution@swift.org>, wrote:

Hello swift evolution, I would like to propose a unified approach to
`random()` in Swift. I have a simple implementation here
https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5\. This
implementation is a simple wrapper over existing random functions so
existing code bases will not be affected. Also, this approach introduces a
new random feature for Linux users that give them access to upper bounds,
as well as a lower bound for both Glibc and Darwin users. This change would
be implemented within Foundation.

I believe this simple change could have a very positive impact on new
developers learning Swift and experienced developers being able to write
single random declarations.

I’d like to hear about your ideas on this proposal, or any implementation
changes if need be.

- Alejando

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

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

Alejandro · November 6, 2017, 12:33am

[Proposal] Random Unification by Azoy · Pull Request #760 · apple/swift-evolution · GitHub is the current API and proposed solution.

- Alejandro

···

On Nov 5, 2017, 6:18 PM -0600, Xiaodi Wu <xiaodi.wu@gmail.com>, wrote:
My comments are directed to the "more up-to-date" document that you just linked to in your reply to Jon. Is that one outdated? If so, can you send a link to the updated proposal and implementation for which you're soliciting feedback?

On Sun, Nov 5, 2017 at 6:12 PM, Alejandro Alonso <aalonso128@outlook.com<mailto:aalonso128@outlook.com>> wrote:
The proposal and implementation have the current updated API. The link I sent Jon was the one I brought up a few weeks ago which is outdated now. The proposal answers all of your questions. As for `.random` being a function, some would argue that it behaves in the same way as `.first` and `.last` which are properties.

- Alejandro

On Nov 5, 2017, 6:07 PM -0600, Xiaodi Wu <xiaodi.wu@gmail.com<mailto:xiaodi.wu@gmail.com>>, wrote:
A few quick thoughts: