Just to clarify for myself. This means that using next() on the Iterator of a 'normal' Sequence like this [...] is a completely legitimate pattern
It really depends on what you mean by "legitimate".
If I saw someone writing that exact code, as you have it, in a code review, I would tag it as needing to be changed to a
for...in loop before merging. It is clearly incorrect from a code style POV, even though the code is "correct" in that it will produce the right output.
Random.default.next() is the same. It is possible the user wants
UInt64.random(in: .min ... .max), and this would be a technically correct way to achieve the same thing. But the latter form is explicit about this being the intent. The former invites a suspicion that the user really wants something else (say, they really wanted an
Int, or they subsequently narrow the range). As ever, encouraging clarity at the point of use is our primary goal in naming things. The API as it currently stands invites lack of clarity.
Worse, it encourages misuse. I fully expect that if
Random.default remains in the language, then you will immediately start seeing something like the following appear in code:
let i = Int(Random.default.next() % n)
Unlike the other examples, this code is explicitly incorrect. It has a bug – a subtle one regarding modulo bias that most users will never know about.
Just search GitHub for occurrences of
"arc4random %" to see this play out in practice. Autocomplete encourages people to use the first thing they stumble over. Despite
arc4random_uniform existing, people discover
arc4random first, and then improvise what they want based on that. With this API, people will type
Random, spot the
default property (hey, the default is supposed to be what you use, like with other APIs, right?), then roll with it, despite the higher-level APIs being a better choice.
As I mentioned earlier, the extent to which people are objecting to the longer name in this thread being something that will look bad in code really does lead me to think that the name
Random.default is highly misleading, in that it suggests this is something you should use actively in code.
Brent's comments about how the longer name will make already-verbose definitions of random generation of user-defined types is a good one, however this is still to my mind a small problem compared to the great risk of encouraging thousands of programmers to use the API incorrectly in client code.