[swift-evolution] [Proposal] Random Unification

[Xiaodi Wu]

My comments are directed to the "more up-to-date" document that you just
linked to in your reply to Jon. Is that one outdated? If so, can you send a
link to the updated proposal and implementation for which you're soliciting
feedback?


On Sun, Nov 5, 2017 at 6:12 PM, Alejandro Alonso <aalonso128 at outlook.com>
wrote:

> The proposal and implementation have the current updated API. The link I
> sent Jon was the one I brought up a few weeks ago which is outdated now.
> The proposal answers all of your questions. As for `.random` being a
> function, some would argue that it behaves in the same way as `.first` and
> `.last` which are properties.
>
> - Alejandro
>
> On Nov 5, 2017, 6:07 PM -0600, Xiaodi Wu <xiaodi.wu at gmail.com>, wrote:
>
> 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/f9d0c736/attachment.html>