[swift-evolution] [Proposal] Random Unification

[Xiaodi Wu]

xoroshiro128+ is not a cryptographically secure algorithm and would not be
incorporated into the Random API, though it is trivial to implement your
own; the proposal outlines sources of randomness that are cryptographically
secure.


On Wed, Dec 20, 2017 at 09:46 Jens Persson via swift-evolution <
swift-evolution at swift.org> wrote:

> I'd like to add a pointer to the information here:
> http://xoroshiro.di.unimi.it
>
> since AFAICS, the xoroshiro128+ generator and the method of "Generating
> uniform doubles in the unit interval" should probably be implemented in any
> modern general purpose Random API.
>
> Please correct me if there are more up to date (higher quality and faster)
> general purpose generators and ways of converting UInt64 bit patterns to
> floating point [0, 1).
>
> /Jens
>
>
>
> On Sun, Dec 3, 2017 at 4:50 AM, Dave Abrahams via swift-evolution <
> swift-evolution at 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).  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 at swift.org> wrote:
>>
>>
>> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution at 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 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
>>
>>
> _______________________________________________
> 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/20171220/e53116ed/attachment.html>