> On Nov 30, 2017, at 4:46 PM, Jonathan Hull <[email protected]> wrote: > >> >> On Nov 30, 2017, at 3:19 PM, Dave DeLong <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >>> On Nov 30, 2017, at 4:08 PM, Jonathan Hull <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>>> On Nov 30, 2017, at 1:58 PM, Dave DeLong <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> >>>>> On Nov 30, 2017, at 2:48 PM, Jonathan Hull via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>> I would personally go with: >>>>> >>>>> Int.random //Returns a random Int >>>> >>>> “Type.random” is so rarely used as to not be worth the addition, IMO. If >>>> you really need a random element from the *entire* domain, then I think >>>> you should have to manually create the ClosedRange<T> yourself. >>> >>> What evidence do you have that this will not be used often? There are many >>> types which aren’t comparable, and thus can’t have a ClosedRange. Bool, >>> for example, would definitely require Bool.Random. I certainly use the >>> full range of UInt and UInt8 on a regular basis (less so with Int). >> >> Bool doesn’t necessarily need “Bool.random”. You just just as easily do >> “[true, false].random()” > > I suppose you can do that, but [true, false].randomElement() is much less > efficient than Bool.random(). You are creating an array each time you need a > Bool, which in some of my use-cases, is pretty often.
So… keep the array around in memory so you don’t have to recreate it… > > >> As for evidence… my own experience. Other than small-value types (like >> Bool), it is *exceptionally* rare to come across a situation where you need >> a random from the entire range. Random colors are interesting, but are rare >> because they can’t guarantee design aesthetic. Random Dates are nonsensical. >> Random Ints are maybe useful, but again, you almost always need a random Int >> from a range of possible values. > > The fact that you haven’t needed it in your personal use cases isn’t evidence > that others don’t need it. Yes, of course. But no where on this thread have I seen a compelling example of generating a random value from all possible values. Have I missed one? > > >>> I think it is important to have Type.random as the base because there are >>> many types which would conform (not just Int & Double). For example, I >>> might have an enum which returns a random case from MyEnum.random. How >>> would you do that if random(in:) was the required base? >> >> I actually don’t think there should be a static “random()” method. I think >> it should be a member function, not a type function. > > I don’t understand this. What would 1.random() do? Well, if such an API existed, it would return “1”. However, since “1” isn’t a collection or range or whatever, this API wouldn’t even exist. > > >> As for picking a random enum, see the previous bit about picking a random >> bool. And that will get even easier once we get the patch where enums have a >> static value listing all their cases, such as “CardSuits.allValues.random()”. > > This would use .randomElement(). I think it is important to have a different > name for generating a random value and picking a random element from a > collection to avoid conflating the two. What is the useful distinction between generating a random value, and choosing a random element from a collection of all possible values? Dave > > >>>>> Int.random(in: ClosedRange<Int>) //Works for Comparable types. Gives a >>>>> result from the closed range. Closed Range is never empty. >>>> >>>> This is redundant. In order to pick a random element, you’re saying I >>>> should have to do “Int.random(0 ..< 10)”? The redundancy here is that I >>>> have to specify Int twice: once for the “.random” call, and again for the >>>> type of the range. We can do better than that. >>> >>> You didn’t have to specify it twice. You used integer literals for the >>> range, which you could also do for Double or CGFloat. Also, I am proposing >>> that we require a closed range, which would mean you would have to do >>> Int.random(0…9). Otherwise we have to deal with ranges which are possibly >>> empty. >> >> “0…9.random()” makes more sense to me than “Int.random(in: 0…9)". It makes >> it easier to change the type, and it doesn’t require me to know a priori the >> type of the range I’m dealing with. > > > I think you could have both Int.random(in: 0…9) and (0…9).randomElement() > without issue. You could even argue for conditionally conforming ranges and > allowing (0…9).random(), though it might be a harder sell. > > Note that Int.random(in:) returns an ‘Int', and Range<Int>.randomElement() > returns an ‘Int?' > > Thanks, > Jon
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
