<div dir="ltr">On Fri, Nov 17, 2017 at 10:10 AM, Gwendal Roué via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
> Le 17 nov. 2017 à 16:04, Alejandro Alonso via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> a écrit :<br>
><br>
> 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.<br>
><br>
> - Alejandro<br>
<br>
</span>Hello,<br>
<br>
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:<br>
<br>
- Int.random is _always_ followed by % modulo. Unless the better arc4random_uniform(max) is used.<br>
- Color.random is _never_ used, because random colors look bad.<br>
- Date.random is _never_ used, because time is a physical unit, and random points in time do not match any physical use case.<br>
<br>
This does not mean that random values from the full domain are useless. Of course not: math apps, fuzzers, etc. need them.<br>
<br>
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.<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div> </div></div></div></div>