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...
}
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]> 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
>
> _______________________________________________
> 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
