[swift-evolution] [Proposal] Random Unification

[Kevin Nattinger]

> On Sep 8, 2017, at 2:46 PM, Jacob Williams via swift-evolution <swift-evolution at swift.org> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <shawnce at gmail.com <mailto:shawnce at gmail.com>>, 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170908/2021f6a3/attachment.html>