[swift-evolution] [Proposal] Random Unification

[Dave DeLong]

> On Nov 30, 2017, at 4:46 PM, Jonathan Hull <jhull at gbis.com> wrote:
> 
>> 
>> On Nov 30, 2017, at 3:19 PM, Dave DeLong <swift at davedelong.com <mailto:swift at davedelong.com>> wrote:
>> 
>> 
>> 
>>> On Nov 30, 2017, at 4:08 PM, Jonathan Hull <jhull at gbis.com <mailto:jhull at gbis.com>> wrote:
>>> 
>>> 
>>>> On Nov 30, 2017, at 1:58 PM, Dave DeLong <swift at davedelong.com <mailto:swift at davedelong.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Nov 30, 2017, at 2:48 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171130/736ca679/attachment.html>