> On 8 Sep 2017, at 23:01, Matthew Johnson via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Sep 8, 2017, at 2:30 PM, Ben Cohen via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> 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. > > How would this design address the relatively common use case of wanting a > random floating point number in the range `0…1` or `0..<1`? Floating point > ranges are not countable.
Perhaps we should special case floating point ranges. Not sure we can generalise anything in that case. >> >> Regards, >> Ben >> >> >>> On Sep 8, 2017, at 10:34 AM, Alejandro Alonso via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@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 <shaw...@gmail.com >>> <mailto:shaw...@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
