Huge +1 to stdlib (or even Foundation) random number generator. I’ve worked with random numbers on both Linux and macOS/iOS and have found myself annoyed with the lack of easy random number generators. It seems that implementing a pure Swift RNG would be an obviously good addition to the stdlib.
I don’t think that it would be possible to make this work for floating point numbers. Although admittedly, I know very little about Floating Point numbers. I think this is still a worthwhile addition to Swift even for just Integers alone. > On Sep 8, 2017, at 1:30 PM, Ben Cohen via swift-evolution > <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. > > 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 > > _______________________________________________ > 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
