<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 8, 2017, at 2:46 PM, Jacob Williams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">What if we did it with something like this:<div class=""><br class=""></div><div class="">protocol RandomGenerator {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>associated type T: Numeric // Since numeric types are the only kinds where we could get a random number?</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func uniform() -> T</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Other random type functions...</div><div class="">}</div></div></div></blockquote><br class="">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.<div class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">I’m no pro and really haven’t thought about this too deeply. Mostly just spitballing/brainstorming.</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 8, 2017, at 3:03 PM, Jacob Williams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 8, 2017, at 1:30 PM, Ben Cohen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Alejandro,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""> - a very common use case is picking a random entry from a collection, which this would do automatically</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""> - 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)</div><div class=""> - since both kinds of countable ranges are collections, it sidesteps that issue :)</div><div class=""> - 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</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.<br class=""></div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Ben</div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 8, 2017, at 10:34 AM, Alejandro Alonso via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<title class=""></title>
<div class="">
<div name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class="">
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`?</div>
<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class="">
<br class="">
On Sep 8, 2017, 12:08 PM -0500, Shawn Erickson <<a href="mailto:shawnce@gmail.com" class="">shawnce@gmail.com</a>>, wrote:<br class="">
<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;" class="">
It would be nice to leverage range support instead of a start and end value IMHO.<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Fri, Sep 8, 2017 at 9:52 AM Alejandro Alonso via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #e67e22;">
<div class="">
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif" class="">
Hello swift evolution, I would like to propose a unified approach to `random()` in Swift. I have a simple implementation here <a href="https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5" target="_blank" class="">https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5</a>.
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.
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">I’d like to hear about your ideas on this proposal, or any implementation changes if need be.</div>
<div class=""><br class="">
</div>
<div class="">- Alejando</div>
</div>
<div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif" class="">
<br class="">
<div class=""></div>
</div>
</div>
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote>
</div>
</blockquote>
<div class=""></div>
</div>
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>