[swift-evolution] [Proposal] Random Unification

[Xiaodi Wu]

That’s the point. Using “Int.random(in: 0...9)” gives you a result that has
an equal chance of being any integer between zero and nine, while
“Int.random % 9” does not.


On Fri, Nov 17, 2017 at 17:30 Jonathan Hull <jhull at gbis.com> wrote:

> Just to play devil’s advocate, wouldn’t they see random(in:) in the
> autocomplete when typing ‘random’?
>
> Thanks,
> Jon
>
> On Nov 17, 2017, at 3:09 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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.
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171118/ad946053/attachment.html>