[swift-evolution] [Proposal] Random Unification

Alejandro Alonso aalonso128 at outlook.com
Fri Nov 17 11:03:00 CST 2017


I can think of many cases where you actually need a random color, not because it doesn’t look good, but because you need a color you don’t have. 

The proposed solution most definitely includes a range based random api for those who don’t need the full domain (0 ..< 10).random. What I’m trying to express is that some people need the full domain (Type.random) and some need the range based api ((min ..< max).random) (or ...). The proposed solution covers both of these and provides solutions to each.

- Alejandro

El nov. 17, 2017, a la(s) 10:10, Gwendal Roué <gwendal.roue at gmail.com> escribió:

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