> On Nov 30, 2017, at 3:19 PM, Dave DeLong <sw...@davedelong.com> wrote: > > > >> On Nov 30, 2017, at 4:08 PM, Jonathan Hull <jh...@gbis.com >> <mailto:jh...@gbis.com>> wrote: >> >> >>> On Nov 30, 2017, at 1:58 PM, Dave DeLong <sw...@davedelong.com >>> <mailto:sw...@davedelong.com>> wrote: >>> >>> >>> >>>> On Nov 30, 2017, at 2:48 PM, Jonathan Hull via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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. > 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. >> 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? > 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. >>>> 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
