> On Sep 8, 2017, at 2:46 PM, Jacob Williams via swift-evolution > <[email protected]> wrote: > > What if we did it with something like this: > > protocol RandomGenerator { > associated type T: Numeric // Since numeric types are the only kinds > where we could get a random number? > func uniform() -> T > // Other random type functions... > }
I support a protocol, but not one with an associated type; those are an enormous pain in the rear to work with. They're quite probably my biggest gripe with Swift (and it's not a short list). I shouldn't have to make an entire class generic just so I can have an RNG that I'll probably want to be a private field anyway. > > Although if we didn’t constrain T to Numeric then collections could also > conform to it, although I’m not sure that collections would want to directly > conform to this. There may need to be a separate protocol for types with > Numeric indexes? > > I’m no pro and really haven’t thought about this too deeply. Mostly just > spitballing/brainstorming. > >> On Sep 8, 2017, at 3:03 PM, Jacob Williams via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> 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 >>> <[email protected] <mailto:[email protected]>> 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 >>>> <[email protected] <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>>, 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 >>>>> <[email protected] <mailto:[email protected]>> 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 >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
