I think this is a good idea. I start asking questions about what our default generator for linux will be if we use Darwin’s arc4random(3). Do we use Glibc’s random()? If so, what do we seed it with?
- Alejandro On Oct 4, 2017, 6:26 PM -0500, Ben Cohen via swift-evolution <swift-evolution@swift.org>, wrote: On Sep 30, 2017, at 3:23 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote: On Sep 11, 2017, at 9:43 PM, Brent Royal-Gordon <br...@architechies.com<mailto:br...@architechies.com>> wrote: On Sep 9, 2017, at 10:31 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote: - I’d love to see several of the most common random kinds supported, and I agree it would be nice (but not required IMO) for the default to be cryptographically secure. I would be very careful about choosing a "simple" solution. There is a log, sad history of languages trying to provide a "simple" random number generator and accidentally providing a powerful footgun instead. But: - We should avoid the temptation to nuke this mosquito with a heavy handed solution designed to solve all of the world’s problems: For example, the C++ random number stuff is crazily over-general. The stdlib should aim to solve (e.g.) the top 3 most common cases, and let a more specialized external library solve the fully general problem (e.g. seed management, every distribution imaginable, etc). That's not to say we need to have seven engines and twenty distributions like C++ does. The standard library is not a statistics package; it exists to provide basic abstractions and fundamental functionality. I don't think it should worry itself with distributions at all. I think it needs to provide: 1. The abstraction used to plug in different random number generators (i.e. an RNG protocol of some kind). 2. APIs on existing standard library types which perform basic randomness-related functions correctly—essentially, encapsulating Knuth. (Specifically, I think selecting a random element from a collection (which also covers generating a random integer in a range), shuffling a mutable collection, and generating a random float will do the trick.) 3. A default RNG with a conservative design that will sometimes be too slow, but will never be insufficiently random. If you want to pick elements with a Poisson distribution, go get a statistics framework; if you want repeatable random numbers for testing, use a seedable PRNG from XCTest or some other test tools package. These can leverage the standard library's RNG protocol to work with existing random number generators or random number consumers. +1 to this general plan! This pretty much exactly matches my preferences. If random numbers go into the std lib, they should being able to customize the source of randomness for speed or test reproducibility, but default to something sensible without the user having to know it’s configurable. On Darwin that default should be based on arc4random(3). The std lib doesn’t need to provide other non-default random sources. Non-random sources for testing should be part of test frameworks and plug in easily. The proposal should include shuffle and random element from collection, which are much-requested and not really the controversial part so won't hold up the overall progress of the proposal. (and no need for distributions other than uniform IMO, 🇫🇷🐟 or otherwise) -Chris _______________________________________________ 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
