I much prefer the API from Nate Cook compared to the previous proposal. Its simpler, while still very powerful, and closer to Swift conventions (method instead of property).
> On 8 Jan 2018, at 20:02, Nate Cook via swift-evolution > <swift-evolution@swift.org> wrote: > > I created a playground to explore this question, starting with a minimal > subset of the proposal’s additions and building from there. The attached > playground demonstrates what’s possible with this subset on the first page, > then uses subsequent pages to explore how the main random facilities of the > C++ STL work under this model. (In my opinion, they work pretty well!) > > The subset in the playground has three main differences from the proposal: > - It doesn't include a Randomizable protocol or a random property on numeric > types. > - It doesn't include the static random(in:) methods on numeric types, either. > - The RandomNumberGenerator protocol doesn't have an associated type. > Instead, it requires all conforming types to produce UInt64 values. > > I’ve tried to include a bit of real-world usage in the playground to > demonstrate what writing code would look like with these additions. Please > take a look! > > Nate > > <Random.playground.zip> > >> On Dec 2, 2017, at 9:50 PM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org <mailto: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 >> <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 <mailto:swift-evolution@swift.org>> wrote: >> >>> >>>> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution >>>> <swift-evolution@swift.org <mailto: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 <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
