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