[swift-evolution] [Proposal] Random Unification

[Xiaodi Wu]

On Fri, Nov 17, 2017 at 18:10 Xiaodi Wu via swift-evolution <
swift-evolution at swift.org> wrote:

> 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.


(...and nor does “Int.random % 10”. Typo.)


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
>>
>> _______________________________________________
> 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/6afc989f/attachment.html>