That's perfectly fine, I should think. Your 'random' and 'random(using:)' are distinct too.
On Sun, Nov 5, 2017 at 21:32 Alejandro Alonso <[email protected]> wrote: > An error that came up in development, default arguments cannot use > internal types, `shuffle(using:)` and `shuffled(using:)`. To remedy this > issue I would have to add another method requirement with no arguments that > gives a default implementation of using `_Random`. This would work, but > would appear in stdlib documentation as two separate functions. > > - Alejandro > > On Nov 5, 2017, 9:08 PM -0600, Xiaodi Wu <[email protected]>, wrote: > > On Sun, Nov 5, 2017 at 8:21 PM, Alejandro Alonso <[email protected]> > wrote: > >> I can agree with mostly everything in here. I think `.random` on >> `RandomAccessCollection` should mimic the current design with `.first` and >> `.last` by returning an optional. In terms of the naming of this, we have >> to look at how python structures the call site. `random.choice([1, 2, 3, >> 4])` To me this reads, random choice within this array. This works because >> of how it’s called. With the proposed solution, we are calling to get a >> random element directly from the array. So I stick by with naming this >> random. >> >> On the subject of bike shedding the names, I can agree to use >> `RandomNumberGenerator` whole heartily. As for `Randomizable`, I agree >> there might be a better name for this, but the question is what? >> > > That is a good question. I don't like `RandomlySamplable`; it might be > that `Randomizable` could be the least bad option. > > One more comment that I neglected to make. You don't need to use an `enum` > in order to make a type non-initializable. A `struct` can do the same with > a private init. There are established singleton patterns for Swift and an > `enum` with a single case is...atypical. I'm also not sure why this should > be a public type at all. Why expose `Random.default.next()`? Shouldn't the > user always use `T.random`? Afaict, `Random` can be an internal type > `_Random` that the user never sees at all. > > > On Nov 5, 2017, 7:56 PM -0600, Xiaodi Wu <[email protected]>, wrote: >> >> I like this particular version. In particular, the choice of algorithms >> is, afaict, correct and that is incredibly important. I had overlooked that >> `arc4random` is cryptographically secure past a certain version of macOS, >> but you are absolutely right. I am also on board with the fatal error >> suggestion if random entropy is unavailable; I think it must be amply >> documented, though. >> >> I do think, however, that you're overloading too many things into the >> word "random" when they're not the same. Take a look at Python, which is >> pretty widely used for numerics. There's `rand` and `random` for getting a >> random integer or floating-point value, and there's `choice` and `sample` >> for choosing one or more values out of a collection without replacement. >> These are sufficiently different tasks and don't all need to be called >> "random" or satisfy the same requirement of the same protocol. Put another >> way, it's absolutely *not* inconsistent for numeric types to have >> `random()` while collection types have a differently named method. >> >> By contrast, I think the great length of text trying to justify naming >> all of these facilities `random` in order to parallel `first` and `last` >> shows how the proposed design is comparatively weaker. You have to argue >> that (a) `Int.random` shouldn't return an optional value because it'd be >> unwieldy, and therefore `(0..<5).random` shouldn't either because it would >> then be inconsistent; but (b) that `(0..<5).random` should be spelled and >> behave like `(0..<5).first` and `(0..<5).last` even though the user must >> handle empty collections totally differently because the return types are >> not the same. Either `(0..<5).random` should behave analogously to `first` >> and `last` or it should not. If it should, it only makes sense to return a >> result of type `T?`. After all, if a collection doesn't have a `first` >> item, then it can't have a `random` item. Put another way, having a `first` >> item is a prerequisite to having a randomly selectable item. The behavior >> of the Swift APIs would be very consistent if `first` returns `T?` but >> `random` returns `T`. However, I agree that unwrapping `Int.random` every >> time would be burdensome, and it would not make sense to have a type >> support `random` but not have any instantiable values; therefore, returning >> an optional value doesn't make sense, and it follows that `Int.random` >> *shouldn't* behave like `first` or `last`. >> >> Once you stop trying to make what Python calls `rand/randint` and >> `choice/sample` have the same names, then finding a Swifty design for the >> distinct facilities becomes much easier, and it suggests a pretty elegant >> result (IMO): >> >> ``` >> [1, 2, 3, 4].choice // like `first` or `last`, this gets you a value of >> type Int? >> [1, 2, 3, 4].sampling(2) // like `prefix(2)` or `suffix(2)`, this gets >> you a subsequence with at most two elements >> >> Int.random // this gets you a random Int; or it may trap >> Float.random // this gets you a random Float; or it may trap >> ``` >> >> With that, it also becomes clear why--and I agree with you--an >> independent `Int.random(in: 0..<5)` is not necessary. `(0..<5).choice` is >> fine, and it can now appropriately return a value of type `T?` because it >> no longer needs to parallel `Int.random`. >> >> * * * >> >> More in the bikeshedding arena, I take issue with some of the names: >> >> - I reiterate my comment that `Randomizable` is not the best name. There >> are multiple dictionary definitions of "randomize" and one is "make >> unpredictable, unsystematic, or random in order or arrangement." Wikipedia >> gives at least five different contextual meanings for the word. What you're >> doing here is specifically **random sampling** and we can do better to >> clarify that, I think. >> >> - While I agree that `RNG` can be cryptic, the alternative should be >> `RandomNumberGenerator` (as it's called in other languages); >> `RandomGenerator` is not quite accurate. Again, we're _consuming_ >> randomness to _generate_ numbers (or values of other type, based on the >> result of a generated number). We're not _generating_ randomness. >> >> >> On Sun, Nov 5, 2017 at 6:33 PM, Alejandro Alonso <[email protected]> >> wrote: >> >>> https://github.com/apple/swift-evolution/pull/760 is the current API >>> and proposed solution. >>> >>> - Alejandro >>> >>> On Nov 5, 2017, 6:18 PM -0600, Xiaodi Wu <[email protected]>, wrote: >>> >>> 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 <[email protected] >>> > 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 <[email protected]>, 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 < >>>> [email protected]> 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 <[email protected]>, 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 < >>>>> [email protected]> 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 < >>>>> [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. 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] >>>>> 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
