SE-0202 Amendment: Naming of the standard library random number generator

[Alejandro (Alejandro Alonso)]

@gwendal.roue

it looks like Random is a namespace, designed to welcome some future random-related APIs, including generators: Random.xorshift128Plus, etc.

I said could
The current design states that Random is the default generator, rather than some empty namespace. Ben is suggesting that this name is:

@bzamayo

is far too generic and does not allude to the fact that other sources of randomness can (and should) exist

There is a term-of-art justification for this name as well. In many languages, such as Java, Scala, Kotlin, D, C# (.NET), Ruby, this spelling is consistently used as the stdlib RNG. Now I understand Swift isn't one of these other languages, but I think it's important to evaluate what other languages have done. Granted these languages get most (if not all?) of their random functionality from this Random type, but it still acts as the stdlib RNG that these languages use. I'm still under the opinion that this spelling still expresses that it is the stdlib RNG. I think in combination with the spelling of the static property default this further explains that this is obviously the stdlib RNG. As for not alluding to the fact that other generators can exist, I disagree entirely. This would be true if we did not come up with something like RandomNumberGenerator, but we made a public utility that many others can build from in addition to the stdlib RNG.

@bzamayo

The current proposal establishes a pattern of adding random-related convenience functions as extensions to instances or types. So Random.default.fillBuffer() would be expressed as something like Buffer.randomBytes(byteCount:using:) at the type level or buffer.randomizeBytes(using:) on an instance. The using argument is optional, defaulting to the stdlib RNG’s source

These extensions that users are creating also implies that they are allowing a default method to utilize Random.default which is why I believe this API will be used more commonly than what you think. I agree that the proposal establishes this pattern, but we would still need this method on generators as well (for one is to really juice the performance out of Random.default). So again, I disagree that this is an API that will be rarely used.

@bzamayo

The idea that Random can act as a namespace is neat, but this intent is not described in the original proposal at all.

The proposal doesn't mention this because Random doesn't necessarily need to attribute itself with the namespacing idea. It needs to be the stdlib RNG. If the discussion for extended random behaviors come up at a future date, this is an alternative design that could be used. Such design would need many months of Swift bikeshedding of course

@bzamayo

When I read the original proposal, I was thinking that Xorshift128RNG (eg) and DefaultRandomNumberGenerator would simply sit alongside each other as top-level types.

And they most certainly could. I was simply stating that the current design could allow for such alternative designs.

At the end of the day, I think this comes down to subjective opinions about how to spell an API. During the pitch phase and most of the review phase this idea that the naming for Random.default would cause active harm to users never came up (maybe my memory is failing me). Maybe it was overlooked, or maybe some didn't care, but I don't believe that this spelling would cause any active harm. Again, I'm not seeing how DefaultRandomNumberGenerator.shared is vastly superior to what is already accepted besides screaming the fact that it's the default RNG. But even then, I think Random does this very well because of whats precedent.