On Fri, Nov 17, 2017 at 18:10 Xiaodi Wu via swift-evolution < swift-evolution@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 <jh...@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@swift.org> wrote: >> >> On Fri, Nov 17, 2017 at 10:10 AM, Gwendal Roué via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> >>> > Le 17 nov. 2017 à 16:04, Alejandro Alonso via swift-evolution < >>> swift-evolution@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
