[swift-evolution] [Proposal] Random Unification

[Ben Cohen]

Hi Alejandro,

I’m really happy to see someone pick this up. We had suggested some kind of random support could be a goal for addition to the standard library in Swift 4 phase 2 but didn’t manage it, so I definitely think a good proposal would be given consideration for Swift 5.

Regarding the implementation – I would suggest exploring something along the lines of an extension on RandomAccessCollection that adds a property for a random element, rather than a pair of free functions. This would have a number of benefits:

 - a very common use case is picking a random entry from a collection, which this would do automatically
 - it gives you a very natural way of expressing a ranged random number i.e. (0..<10).randomElement (not necessarily recommending that name btw, it’s one of various possibilities)
 - since both kinds of countable ranges are collections, it sidesteps that issue :)
 - it allows for multiple different integers without the need for casting i.e. in the above, if type context meant the result was a UInt16, that’s what it would be

The one downside is that you’d have to write (0..<Int.max). This might be a justification for a static property on one of the Integer protocols as shorthand for that.

The tricky part (in addition to the cross-platform aspect) is ensuring correct distribution across the possible distances. But since this is something that people might easily get wrong, that reinforces the idea of this being something that’s easy to use correctly in the std lib.

I’d also suggest proposing a shuffle implementation for RandomAccessCollection+MutableCollection at the same time (probably as a separate but linked proposal), since this is also something that is often requested, easy to get wrong, and needs a cross-platform source of random numbers.

Regards,
Ben


> On Sep 8, 2017, at 10:34 AM, Alejandro Alonso via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Range support is something that came up, and I think it’s a great idea as well. My question now is do we support both `CountableRange` and `CountableClosedRange`?
> 
> On Sep 8, 2017, 12:08 PM -0500, Shawn Erickson <shawnce at gmail.com>, wrote:
>> It would be nice to leverage range support instead of a start and end value IMHO.
>> On Fri, Sep 8, 2017 at 9:52 AM Alejandro Alonso via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Hello swift evolution, I would like to propose a unified approach to `random()` in Swift. I have a simple implementation here https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5 <https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5>. This implementation is a simple wrapper over existing random functions so existing code bases will not be affected. Also, this approach introduces a new random feature for Linux users that give them access to upper bounds, as well as a lower bound for both Glibc and Darwin users. This change would be implemented within Foundation.
>> 
>> I believe this simple change could have a very positive impact on new developers learning Swift and experienced developers being able to write single random declarations.
>> 
>> I’d like to hear about your ideas on this proposal, or any implementation changes if need be.
>> 
>> - Alejando
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170908/08c6b5a4/attachment.html>