[swift-evolution] [Proposal] Random Unification

[Xiaodi Wu]

A few quick thoughts:

I know that there's been some discussion that `(1...10).random` is the best
spelling, but I'd like to push back on that suggestion. When I want a
random number, I tend to think of the type I want first ("I want a random
integer") and then a range ("I want a random integer between a and b"), not
the other way around. My intuition is that `Int.random(in:)` will be more
discoverable, both on that basis and because it is more similar to other
languages' syntax (`Math.random` in JavaScript and `randint` in NumPy, for
example). It also has the advantage that the type is explicit, which I
think is particularly useful in this case because the value itself is,
well, random.

I would also argue that, `random` is most appropriately a method and not a
property; there's no hard and fast rule for this, but the fact that the
result is stochastic suggests (to me) that it's not a "property" of the
range (or, for that matter, of the type).

I would reiterate here my qualms about `Source` being the term used for a
generator. These types are not a _source_ of entropy but rather a
_consumer_ of entropy.

`UnsafeRandomSource` needs to be renamed; "unsafe" has a specific meaning
in Swift--that is, memory safety, and this is not it. Moreover, it's
questionable whether this protocol is useful in any sense. What useful
generic algorithms can one write with such a protocol?

`XoroshiroRandom` cannot be seeded by any `Numeric` value; depending on the
specific algorithm it needs a seed of a specific bit width. If you default
the shared instance to being seeded with an `Int` then you will have to
have distinct implementations for 32-bit and 64-bit platforms. This is
unadvisable. On that note, your `UnsafeRandomSource` needs to have an
associated type and not a generic `<T : Numeric>` for the seed.

The default random number generator should be cryptographically secure;
however, it's not clear to me that it should be device random.

I agree with others that alternative random number generators other than
the default RNG (and, if not default, possibly also the device RNG) should
be accommodated by the protocol hierarchy but not necessarily supplied in
the stdlib.

The term `Randomizable` means something specific which is not how it's used
in your proposed protocol.

There's still the open question, not answered, about how requesting an
instance of the hardware RNG behaves when there's insufficient or no
entropy. Does it return nil, throw, trap, or wait? The proposed API does
not clarify this point, although based on the method signature it cannot
return nil or throw. Trapping might be acceptable but I'd be interested to
hear your take as to why it is preferable.


On Sun, Nov 5, 2017 at 4:43 PM, Alejandro Alonso via swift-evolution <
swift-evolution at swift.org> wrote:

> For the proof of concept, I had accidentally deleted that one. I have a
> more up to date one which was discussed a few weeks later.
> https://gist.github.com/Azoy/15f0518df38df9b722d4cb17bafea4c1
>
> - Alejandro
>
> On Nov 5, 2017, 4:37 PM -0600, Jonathan Hull <jhull at gbis.com>, wrote:
>
> Is there a link to the writeup?  The one in the quote 404s.
>
> Thanks,
> Jon
>
> On Nov 5, 2017, at 2:10 PM, Alejandro Alonso via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hello once again Swift evolution community. I have taken the time to write
> up the proposal for this thread, and have provided an implementation for it
> as well. I hope to once again get good feedback on the overall proposal.
>
> - Alejandro
>
> On Sep 8, 2017, 11:52 AM -0500, Alejandro Alonso via swift-evolution <
> 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. 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
> 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/20171105/dde64960/attachment.html>