Re: [swift-evolution] [Proposal] Random Unification

:52 AM, Alejandro Alonso via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@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/5d294148c8b97d

Re: [swift-evolution] [Proposal] Random Unification

I think this is a good idea. I start asking questions about what our default generator for linux will be if we use Darwin’s arc4random(3). Do we use Glibc’s random()? If so, what do we seed it with? - Alejandro On Oct 4, 2017, 6:26 PM -0500, Ben Cohen via swift-evolution

Re: [swift-evolution] [Proposal] Random Unification

I agree with Ben here because users can still enter an invalid range with the static function. I.E. Int.random(in: 0 ... 0). I would really prefer excluding these static functions from numeric types. - Alejandro El oct. 5, 2017, a la(s) 12:03, Nate Cook via swift-evolution

Re: [swift-evolution] [Proposal] Random Unification

Rather 0 ..< 0 my bad. I think if we include closedcountable, then there needs to be support for countable, but there are edge cases where users can input invalid ranges for countable. Enviado desde mi iPhone El oct. 5, 2017, a la(s) 12:22, Alejandro Alonso via swift-evolution <

Re: [swift-evolution] [Proposal] Random Unification

nstead of a start and end value IMHO. On Fri, Sep 8, 2017 at 9:52 AM Alejandro Alonso via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote: Hello swift evolution, I would like to propose a unified approach to `random()` in Swift. I have a simple implemen

Re: [swift-evolution] [Proposal] Random Unification

I really like the schedule here. After reading for a while, I do agree with Brent that stdlib should very primitive in functionality that it provides. I also agree that the most important part right now is designing the internal crypto on which the numeric types use to return their respected

Re: [swift-evolution] [Proposal] Random Unification

would be awkward.) In addition, this alternative approach could make creating random values more consistent with types that don’t work well in ranges: Data.random(bytes: 128) Color.random(r: 0...0, g: 0...1, b: 0...1, a: 1...1) ———— Thanks again! Nate On Nov 5, 2017, at 6:33 PM, Alejand

Re: [swift-evolution] [Proposal] Random Unification

hat Bool would be awkward.) In addition, this alternative approach could make creating random values more consistent with types that don’t work well in ranges: Data.random(bytes: 128) Color.random(r: 0...0, g: 0...1, b: 0...1, a: 1...1) Thanks again! Nate On Nov 5, 2017, at 6:33 PM, Alej

Re: [swift-evolution] [Proposal] Random Unification

Regarding naming too many things “random”, I’ve talked to many developers on my end and they all don’t find it confusing. This proposal is aimed to make it obvious what the operation is doing when regarding random. I still agree that the proposed solution does just that and in practice feels

Re: [swift-evolution] [Proposal] Random Unification

ué via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote: > Le 17 nov. 2017 à 16:04, Alejandro Alonso via swift-evolution > <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> a écrit : > > If we go back to your exampl

Re: [swift-evolution] [Proposal] Random Unification

Like I’ve said, python has different syntax grammar. We have to read each call site and form a sentence from it. `random.choice([1, 2, 3])` to me this reads, “Get a random choice from array”. This makes sense. Slapping the word choice as an instance property like `[1, 2, 3].choice` reads, “From

Re: [swift-evolution] [Proposal] Random Unification

pproach could make creating random values more consistent with types that don’t work well in ranges: Data.random(bytes: 128) Color.random(r: 0...0, g: 0...1, b: 0...1, a: 1...1) Thanks again! Nate On Nov 5, 2017, at 6:33 PM, Alejandro Alonso via swift-evolution <swift-evolution

Re: [swift-evolution] [Proposal] Random Unification

gmail.com> escribió: > >> Le 17 nov. 2017 à 16:04, Alejandro Alonso via swift-evolution >> <swift-evolution@swift.org> a écrit : >> >> If we go back to your example, you never call FixedWidthInteger.random >> either, you call range.random. Does this mean in

Re: [swift-evolution] [Proposal] Random Unification

Nov 16, 2017, at 8:12 PM, Alejandro Alonso via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote: While this could work, I don’t believe this aligns with Swift. SecRandomCopyBytes and arc4random_buf do it this way because of the la

Re: [swift-evolution] [Proposal] Random Unification

ive approach could make creating random values more consistent with types that don’t work well in ranges: Data.random(bytes: 128) Color.random(r: 0...0, g: 0...1, b: 0...1, a: 1...1) ———— Thanks again! Nate On Nov 5, 2017, at 6:33 PM, Alejandro Alonso via swift-evolution <swift-evol

Re: [swift-evolution] [Proposal] Random Unification

While this could work, I don’t believe this aligns with Swift. SecRandomCopyBytes and arc4random_buf do it this way because of the languages they were built in, and for SecRandomCopyBytes, it needs to also return an error (in the form of its return value). For custom generators this doesn’t

Re: [swift-evolution] [Proposal] Random Unification

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@swift.org<mailto:swift-evolution@sw

Re: [swift-evolution] [Proposal] Random Unification

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@swift.org<mailto:swift-evolution@swift.org>> wrote: Hello once again Swift evolution community. I have taken the time to write up the propos

Re: [swift-evolution] [Proposal] Random Unification

ed 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@swift.org<mailto:s

Re: [swift-evolution] [Proposal] Random Unification

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

Re: [swift-evolution] [Proposal] Random Unification

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@swift.org<mailto:swift-evol

Re: [swift-evolution] [Proposal] Random Unification

he 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@swift.org<mailto:swift-evolution@swift.org

Re: [swift-evolution] [Proposal] Random Unification

posed 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-evolutio

Re: [swift-evolution] [Proposal] Random Unification

I made changes last night that uses methods rather than properties if that’s all you’re worried about. Sent from my iPhone On Jan 8, 2018, at 15:27, David Hart via swift-evolution > wrote: I much prefer the API from Nate Cook

Re: [swift-evolution] [Proposal] Random Unification

Give up* Sent from my iPhone On Jan 12, 2018, at 08:10, Alejandro Alonso via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote: I am willing to give `.random()`. However I still wish to preserve `.random(in:)` and `.random()` on Bool. Sent fr

Re: [swift-evolution] [Proposal] Random Unification

Done and done! Sent from my iPhone On Jan 12, 2018, at 01:22, Nate Cook > wrote: On Jan 11, 2018, at 9:17 PM, Alejandro Alonso > wrote: Sorry it takes me forever to respond! I finally got

Re: [swift-evolution] [Proposal] Random Unification

(0 ..< 10).random() would return an optional Int.random(in: 0 ..< 10) would return a non optional (this is the one that crashes on bad range) Sent from my iPhone On Jan 12, 2018, at 07:11, Letanyan Arumugam > wrote: Nate’s design follows a

Re: [swift-evolution] [Proposal] Random Unification

Sorry it takes me forever to respond! I finally got around to writing this! School really takes all my time x) I have a few ideas on where we can go with this: 1. I agree, we should ditch `Randomizable` as something like that should belong in a separate library or written by the user. 2. I

Re: [swift-evolution] [Proposal] Random Unification

If anything, Nate’s design is inconsistent as properties like `.first` and `.last` return an optional, and methods like `.min()` and `.max()` return an optional as well. Having `.random()` on ranges be an exception and return non optionals are inconsistent with other collection facilities, and

Re: [swift-evolution] [Proposal] Random Unification

Alonso via swift-evolution <swift-evolution@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 wrappe

Re: [swift-evolution] [Proposal] Random Unification

I am willing to give `.random()`. However I still wish to preserve `.random(in:)` and `.random()` on Bool. Sent from my iPhone On Jan 11, 2018, at 21:28, Xiaodi Wu <xiaodi...@gmail.com<mailto:xiaodi...@gmail.com>> wrote: On Thu, Jan 11, 2018 at 9:17 PM, Alejandro Alonso via swi