<div>On Wed, Nov 22, 2017 at 22:55 Alejandro Alonso <<a href="mailto:aalonso128@outlook.com">aalonso128@outlook.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
I pushed some updates to the proposal with a reflected API, but I do not agree that we should rid the API of T.random just because some users will misuse it. I think the correct solution here is to include T.random(in:) (which does not return an optional making
it not a second typing of (min ... max).random). Like Jonathon said, autocomplete will display both of these and users will be able to select random(in:). I also disagree that T.random is _always_ followed by modulo because if we look at arc4random() it’s
range is the whole domain of UInt32. Users don’t put a modulo here because they know the correct way to do it is through arc4random_uniform(), either through online tutorials, or by reading documentation. If we did get rid of T.random, users who want a random
byte for instance would have to write UInt8.random(in: 0 … 255) every time. Developers will make wrappers over this. I believe the correct solution is to keep T.random for those who won’t misuse it and T.random(in:) for those who need to a random value within
a range.</div></div></blockquote><div dir="auto"><br></div><div dir="auto">This is an exceedingly rare use case. Do you think it will be common that a developer will want a single random byte? There will be much better ways to request multiple bytes (through Data, for instance). And if a user wants something like a value between 0...255 specifically, such as in the case of elements of an RGB tuple, then (0...255).random is clearly a superior spelling as compared to UInt8.random.</div><div dir="auto"><br></div><div dir="auto">Quite simply, having seen how it is used in other languages, T.random is vastly more likely to be misused than profitably used, by which I mean used in a situation where an alternative spelling is clearly not good enough. It should not be the simplest API offered, as its correct use is anything but simple.</div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
On Nov 17, 2017, 5:09 PM -0600, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>>, wrote:<br>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #1abc9c">
<div>On Fri, Nov 17, 2017 at 10:10 AM, Gwendal Roué via swift-evolution
<span><<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:5px 5px;padding-left:10px;border-left:thin solid #e67e22">
<span class="m_-9195741636612860653gmail-"><br>
> Le 17 nov. 2017 à 16:04, Alejandro Alonso via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">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>
</blockquote>
</div>
</div></blockquote></div></div>