SE-0202 Amendment Proposal: Rename Random to DefaultRandomNumberGenerator

[Ben_Cohen]

SE-0202, as accepted, introduces a type, Random, as the default source of random numbers on each platform.

As @bzamayo outlines here, the name Random for this default source is misleading, and would probably be better named DefaultRandomNumberGenerator.

The core team agrees, so we're opening up a thread to discuss before accepting this amendment.

One open question is the naming of the getter for an instance of the type. Currently it is Random.default. However, renaming Random leads to the rather clunky DefaultRandomNumberGenerator.default. Benjamin suggests .shared. However, in all current implementations, this is not strictly speaking a shared instance – it is instead a getter/setter for a fresh instance each time. This doesn't actually have a cost, since the type has no actual size (the type is just a vehicle for calling an OS function), but needs to be done this way because using: is taken inout.

Any suggestions for better naming gratefully received.

[phlebotinum (Boris Triebel)]

Perhaps .instance ?

[bzamayo (Benjamin Mayo)]

Just to provide some slight context, the main reason I had suggested shared is because it is really a 'shared' source of randomness. I realise this is a subtlety that is probably confusing, given how singletons tend to use shared properties to refer to true shared instances, and am certainly open to better ideas.

My main issue was with the name of the Random object itself and still support DefaultRandomNumberGenerator (or DefaultRNG as some complained in the discussion thread that the former was simply too long, even though I believe it will be typed rarely and there are mitigations with autocomplete etc.)

[Ben_Cohen]

Thanks @bzamayo – that's a good point. My personal opinion is there's no ideal name and any of default, shared or instance is probably fine. The documentation on a given platform should cover the exact nature of the default instance.

[Erica_Sadun]

Would you consider layering this, retaining Random, and going for Random.DefaultSource.shared? This opens the door for Random.GaussianDistribution, Random.MersenneTwister, Random.ShuffledDistribution, etc, each of which can offer a shared instance?

[BigZaphod (Sean Heber)]

Probably a silly idea, but if there were a common type named Default, you could define it something like:

extension Default {
  static var randomNumberGenerator: RandomNumberGenerator { return ... whatever you want to call it }
}

And this might be a nice home to all sorts of things that have platform defaults or whatever rather than putting static accessors in the main type itself?

[nuclearace (Erik Little)]

I have mixed feelings about this. I do agree that Random as a currency type is probably not the best. However, I do like the idea of a, (pardon the term), namespace that would wrap around various "Random" related items. However given that that is a whole can of worms, I would prefer to just keep it named Random. All the alternatives I've seen are too clunky for my liking.

[cal (Cal Stephens)]

I like the idea of renaming the Random type to DefaultRandomNumberGenerator. That name seems more descriptive of the actual purpose and behavior of the type.

I think it would be unfortunate, though, for the accessor to be so arduously long (e.g. DefaultRandomNumberGenerator.shared). At the call-site itself, Random.default seems descriptive enough while not being overly verbose.

I think this would be a good time to introduce a Random namespace:

enum Random {
    static var default: DefaultRandomNumberGenerator {
        return DefaultRandomNumberGenerator.shared
    }
}

An approach like this would allow us to keep current (and imo better) call-site semantics while updating the type name itself to be less misleading.

Eventually, other types could have accessors in the Random namespace as well. It would also be a good extension point for users to add their own sources of randomness.

[masters3d (Chéyo Jiménez)]

Do we want to do this for all the types that have a default? One occurrence of this naming should not really push the standard library to enforce this naming.

I think we need a more complete approach to default values. I worry that creating a precedence for the name default to be at the beginning is just avoid the problem.

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

I do not think this is more discoverable or more readable. I think I would much rather have a system to getting default values for any type as in C# default() ala default(RandomNumberGenerator) but since we do know have that then it makes sence for this to live in Random since random implements the RandomNumberGenerator protocol I do not like the idea of a static/singleton like shared unless it is necessary (as in, would this be a class then or have reference semantics?) but in this case it see…

[Ben_Cohen]

I think it would be unfortunate, though, for the accessor to be so arduously long (e.g. DefaultRandomNumberGenerator.shared ). At the call-site itself, Random.default seems descriptive enough while not being overly verbose.

I don't think it's really expected that you would ever see DefaultRandomNumberGenerator.shared at a call site. Given it's the default and all.

The one place users will need it is when defining their own random methods in parallel to the std lib ones, so they can have the same default. The length of the name doesn't seem particularly burdensome for this rare case.

[Ben_Cohen]

if there were a common type named Default, you could define it something like:

extension Default

This is an interesting notion – and is immediately interesting for our purposes here because it suggests an alternative possible namespace into which the default source of randomness could go.

Given it's unclear whether the std lib is the right place, long term, for other random-related things (as opposed to such things as distributions belonging in a separate package), it seems inappropriate to use this amendment as a vehicle for creating such a thing. This amendment is about the immediate need to rename this type to something more appropriate as part of the 4.2 release.

[Erica_Sadun]

This amendment is about the immediate need to rename this type to something more appropriate as part of the 4.2 release.

Then how about DefaultRandomSource.shared? I don't love it but it's shorter. Or RandomSource, which can be distinct from 3rd parties via Swift.RandomSource?:

[Alejandro (Alejandro Alonso)]

We had lengthy discussion in the pitch phase about these kinds of names. These names are not good because the generators themselves are not a source of randomness. For example, calling into /dev/urandom. The file itself sources us randomness while Random takes that and generates a number.

[Alejandro (Alejandro Alonso)]

I would like to echo something I said in the previous thread

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

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.

[AlexanderM (Alexander Momchilov)]

Why are we over complicating this? 99% of the time you have some novice game develop who wants to roll a die or pick a card. They don't care if it's Mersenne Twister or a radioactive-isotope based RNG.

Progressive disclosure.

[Paul_Cantrell]

I like Erica’s idea in particular because it opens the door to a Random.default that points to some standard generator that serves 90% of the need, much in the manner of other languages’ stdlibs, while setting up a sensible naming structure for more specialized RNGs.

If devs have to type DefaultRandomNumberGenerator.shared on a regular basis, Swift will never live it down.

[anon27714269]

DefaultRandomNumberGenerator.shared sound terrible unwieldy to me - Swift should not hold a competition who designs the ugliest and longest name. Were are the good old times of rnd()? Not every problem have to become rocket science 8(

[Ben_Cohen]

If devs have to type DefaultRandomNumberGenerator.shared on a regular basis, Swift will never live it down.

To reiterate: if anyone has to type DefaultRandomNumberGenerator.shared on a regular basis, something has gone horribly wrong. Users are not expected to use this generator directly. They should use the higher-level APIs. They may use a PRNG of their own as an argument to those functions when paramterizing, but wouldn't ever need to pass in the default value.

If we did find people using it often, this would be a sign we've made it too inviting and that the name Random.default could be a cause of this.

[Erica_Sadun]

We had lengthy discussion in the pitch phase about these kinds of names. These names are not good because the generators themselves are not a source of randomness. For example, calling into /dev/urandom . The file itself sources us randomness while Random takes that and generates a number.

One open question is the naming of the getter for an instance of the type. Currently it is Random.default . However, renaming Random leads to the rather clunky DefaultRandomNumberGenerator.default . Benjamin suggests .shared . However, in all current implementations, this is not strictly speaking a shared instance – it is instead a getter/setter for a fresh instance each time. This doesn't actually have a cost, since the type has no actual size (the type is just a vehicle for calling an OS function), but needs to be done this way because using: is taken inout .

It sounds to me that what you want then is a consensus that DefaultRandomNumberGenerator.default is the right name.

Points in favor:

• It is highly descriptive and accurate
• It does not mislead in using default rather than shared as new instances will be created.

Points against:

• The tooling is overly long and difficult to type.
• As @Paul_Cantrell notes, it may produce negative feelings about the language if used by third parties. (Reason: "If we did find people using it often, this would be a sign we've made it too inviting and that the name Random.default could be a cause of this.")

Let me ask:

• Why does there need to be a default member at all rather than using DefaultRandomNumberGenerator()?
• Why not use a static member that's set on first use, that can be shared?
• If it is a (to quote from the first post of this thread) "default source", why not name it using those words or a close equivalent? Or is that just a misstatement that should be ignored?
• Why not create a subtype for the default generator, allowing room for the language to grow or third parties to build on? (Edit: although this might make conformance difficult, and it apparently should not be inviting such customization as this appears to be a type meant to service the rest of the proposal, even though it's visible)

[Paul_Cantrell]

To reiterate: if anyone has to type DefaultRandomNumberGenerator.shared on a regular basis, something has gone horribly wrong. Users are not expected to use this generator directly. … If we did find people using it often, this would be a sign we've made it too inviting and that the name Random.default could be a cause of this.

My apparently incorrect impression was that this name would occasionally should up in practical usage. If that's not the case, then I have no objection to a cumbersome name.