[swift-evolution] [Proposal] Random Unification

[Greg Parker]

> On Nov 22, 2017, at 8:55 PM, Alejandro Alonso via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I pushed some updates to the proposal with a reflected API, but I do not agree that we should rid the API of T.random just because some users will misuse it. I think the correct solution here is to include T.random(in:) (which does not return an optional making it not a second typing of (min ... max).random). Like Jonathon said, autocomplete will display both of these and users will be able to select random(in:). I also disagree that T.random is _always_ followed by modulo because if we look at arc4random() it’s range is the whole domain of UInt32. Users don’t put a modulo here because they know the correct way to do it is through arc4random_uniform(), either through online tutorials, or by reading documentation.

What evidence do you have that "users…know the correct way to do it"?

I searched for arc4random and arc4random_uniform in a large Apple codebase.
723 files used arc4random.
296 files used arc4random_uniform.

By eyeball, at least 80% of the arc4random() uses were of the form
    arc4random() % something
or 
    (some_float_type)arc4random() / something
which are non-uniform ways to get a random integer and floating-point values, respectively.

Few calls to arc4random() were obviously initializing random bytes for purposes like crypto or networking, but much of Apple's crypto code would likely have used other API like arc4random_buf() or CCRandomCopyBytes() so that may not be a good estimate.


-- 
Greg Parker     gparker at apple.com <mailto:gparker at apple.com>     Runtime Wrangler


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171127/5d757583/attachment.html>