[swift-evolution] [Proposal] Random Unification

[Xiaodi Wu]

On Fri, Nov 17, 2017 at 10:10 AM, Gwendal Roué via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > Le 17 nov. 2017 à 16:04, Alejandro Alonso via swift-evolution <
> swift-evolution at swift.org> a écrit :
> >
> > If we go back to your example, you never call FixedWidthInteger.random
> either, you call range.random. Does this mean integer types shouldn’t have
> .random? No, because it means get a random number from it’s internal range
> (alias to (min ... max).random). I think we can all agree that
> Integer.random is a nicer api than making a range of its bounds. The same
> goes for Date.random and Color.random.
> >
> > - Alejandro
>
> Hello,
>
> I'm not random expert, but it has never happened in my developer life
> (backend & frontend app developer) that I have used a pure random value
> from the full domain of the random type. In this life:
>
> - Int.random is _always_ followed by % modulo. Unless the better
> arc4random_uniform(max) is used.
> - Color.random is _never_ used, because random colors look bad.
> - Date.random is _never_ used, because time is a physical unit, and random
> points in time do not match any physical use case.
>
> This does not mean that random values from the full domain are useless. Of
> course not: math apps, fuzzers, etc. need them.
>
> Yet a range-based API would be much welcomed by regular app developers.
> And also Array.randomElement(), Array.shuffled(), etc, because there are
> plenty naive and bad algorithms for those simple tasks.
>

Certainly it's hard to defend Date.random (and yes, it might be useful for
a fuzzer, but that's a very niche use case--and in that case the fuzzer
should probably also generate invalid/non-existent dates, which surely
Date.random should not do). But actually, Int.random followed by % is the
much bigger issue and a very good cautionary tale for why T.random is not a
good idea. Swift should help users do the correct thing, and getting a
random value across the full domain and computing an integer modulus is
never the correct thing to do because of modulo bias, yet it's a very
common error to make. We are much better off eliminating this API and
encouraging use of the correct API, thereby reducing the likelihood of
users making this category of error.

If (and I agree with this) the range-based notation is less intuitive
(0..<10.random is certainly less discoverable than Int.random), then we
ought to offer an API in the form of `Int.random(in:)` but not
`Int.random`. This does not preclude a `Collection.random` API as Alejandro
proposes, of course, and that has independent value as Gwendal says.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171117/48a94179/attachment.html>