[swift-evolution] [Proposal] Random Unification

Gwendal Roué gwendal.roue at gmail.com
Fri Nov 17 10:10:19 CST 2017


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

Gwendal Roué



More information about the swift-evolution mailing list