Unfortunately, it wasn’t my only worry. The simplifications from dropping Randomizable and random(in: ) are also very welcome for me.
> On 8 Jan 2018, at 23:08, Alejandro Alonso <aalonso...@outlook.com> wrote: > > I made changes last night that uses methods rather than properties if that’s > all you’re worried about. > > Sent from my iPhone > > On Jan 8, 2018, at 15:27, David Hart via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> 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 <mailto: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 >>>> <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 >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
