xoroshiro128+ is not a cryptographically secure algorithm and would not be incorporated into the Random API, though it is trivial to implement your own; the proposal outlines sources of randomness that are cryptographically secure.
On Wed, Dec 20, 2017 at 09:46 Jens Persson via swift-evolution < swift-evolution@swift.org> wrote: > I'd like to add a pointer to the information here: > http://xoroshiro.di.unimi.it > > since AFAICS, the xoroshiro128+ generator and the method of "Generating > uniform doubles in the unit interval" should probably be implemented in any > modern general purpose Random API. > > Please correct me if there are more up to date (higher quality and faster) > general purpose generators and ways of converting UInt64 bit patterns to > floating point [0, 1). > > /Jens > > > > On Sun, Dec 3, 2017 at 4:50 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> I don’t have much to say about this other than that I think the >> discussion seems way too narrow, focusing on spelling rather than on >> functionality and composability. I consider the “generic random number >> library” design to be a mostly-solved problem, in the C++ standard >> library (http://en.cppreference.com/w/cpp/numeric/random). Whatever >> goes into the Swift standard library does not need to have all those >> features right away, but should support being extended into something >> having the same general shape. IMO the right design strategy is to *implement >> and use* a Swift version of C++’s facilities and only then consider >> proposing [perhaps a subset of] that design for standardization in Swift. >> >> Sent from my iPad >> >> On Dec 2, 2017, at 5:12 PM, Kyle Murray via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> Instead, we ought to make clear to users both the features and the >> limitations of this API, to encourage use where suitable and to discourage >> use where unsuitable. >> >> >> I like that you're considering the balance here. I've been lightly >> following this thread and want to add my thoughts on keeping crypto and >> pseudorandomness out of the name of at least one random API intended for >> general use. >> >> For someone who doesn't know or care about the subtleties of insecure or >> pseudorandom numbers, I'm not sure that the name insecureRandom is >> effectively much different than badRandom, at least in terms of the >> information it conveys to non-experts. To Greg's point, that's the opposite >> of the signal that the API name should suggest because it's what most >> people should use most of the time. As you say, this API is being designed >> for general use. >> >> There's a cost to adding extra complexity to names, too. I don't think >> it's far-fetched to suspect that people who find insecureRandom in an >> autocomplete listing or search will think "Where's the plain random >> function?"... and then go looking for a community extension that will >> inevitably provide a trivial alias: func random() { return >> insecureRandom() }. That's the sort of adoption I'd expect from >> something for new programmers, like Swift Playgrounds. Someone's >> introduction to randomness in programming should probably involve no more >> than a straightforward mapping from the elementary definition, rather than >> forcing a teaching moment from more advanced math. >> >> I think there are better places for caveat information than in the API >> names themselves; documentation being one clear destination. This is in >> contrast with Unsafe*Pointer, where the safety element is critical >> enough to be elevated to be more than caveat-level information. You can go >> really far and create really cool things before these caveats start to >> apply. Using randomness as a black box in an intro programming environment >> seems like a much more common scenario than someone attempting to roll >> their first crypto by only reading API names and hoping for the best. >> >> -Kyle >> >> _______________________________________________ >> 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 >> >> > _______________________________________________ > 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