Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

+1000 I once made a country code enum, and creating that array was simple, but took forever, and was prone to mistakes. Thanks, Jon > On Sep 8, 2017, at 2:56 AM, Logan Shire via swift-evolution > wrote: > > Googling ‘swift iterate over enum cases’ yields many

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

On 08.09.2017 12:56, Logan Shire via swift-evolution wrote: Googling ‘swift iterate over enum cases’ yields many results of various levels of hackery. Obviously it’s trivial to write a computed property that returns an enum’s cases as an array, but maintaining that is prone to error. If you

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

> On Sep 8, 2017, at 11:32 AM, Tony Allevato wrote: > > > > On Fri, Sep 8, 2017 at 8:35 AM Matthew Johnson > wrote: >> On Sep 8, 2017, at 9:53 AM, Tony Allevato via swift-evolution >>

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

> On Sep 8, 2017, at 9:53 AM, Tony Allevato via swift-evolution > wrote: > > Thanks for bringing this up, Logan! It's something I've been thinking about a > lot lately after a conversation with some colleagues outside of this > community. Some of my thoughts: > >

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

On Fri, Sep 8, 2017 at 8:35 AM Matthew Johnson wrote: > On Sep 8, 2017, at 9:53 AM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote: > > Thanks for bringing this up, Logan! It's something I've been thinking > about a lot lately after a conversation

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

Thanks for bringing this up, Logan! It's something I've been thinking about a lot lately after a conversation with some colleagues outside of this community. Some of my thoughts: AFAIK, there are two major use cases here: (1) you need the whole collection of cases, like in your example, and (2)

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

IMO, we should have a `Random` or `RandomGenerator` interface and the stdlib can provide a `SystemRandom` that wraps arc4*/random(), and maybe a cryptographically secure one too (MT19937?). protocol RandomGenerator { func uniform() -> Int func uniform() -> Double func

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

I think ClosedRange. Also there should be support for floating types. > On Sep 8, 2017, at 12:34 PM, Alejandro Alonso via swift-evolution > wrote: > > Range support is something that came up, and I think it’s a great idea as > well. My question now is do we support

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

It would be nice to leverage range support instead 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> wrote: > Hello swift evolution, I would like to propose a unified approach to > `random()` in Swift. I have a simple

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

I've been waiting for this for years. Literally since Swift was announced. IMO it's one of several major gaps in the language. Some thoughts: - It should be a simple array. - By far the most simple solution, and the one I (and, I'd guess, others) would expect. - Every time I've

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

> On Sep 4, 2017, at 4:05 PM, Christopher Kornher via swift-evolution > wrote: > > Apologies for rehashing this, but we seem to be going down that path… I am in > the minority on this issue and have held my opinions because I thought that > they would have served

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

Quick thoughts: 1. A stdlib-level random number facility should default to a host-provided CSPRNG as the generator. Anything less is really not justifiable. The throughput of modern HW-backed CSPRNGs exceeds that of all but the fastest PRNGs, anyway. 2. MT is not a CSPRNG. – Steve > On Sep

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

Hi Alejandro, I’m really happy to see someone pick this up. We had suggested some kind of random support could be a goal for addition to the standard library in Swift 4 phase 2 but didn’t manage it, so I definitely think a good proposal would be given consideration for Swift 5. Regarding the

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

On Fri, Sep 8, 2017 at 9:44 AM Matthew Johnson wrote: > On Sep 8, 2017, at 11:32 AM, Tony Allevato > wrote: > > > > On Fri, Sep 8, 2017 at 8:35 AM Matthew Johnson > wrote: > >> On Sep 8, 2017, at 9:53 AM, Tony Allevato

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

Range support is something that came up, and I think it’s a great idea as well. My question now is do we support both `CountableRange` and `CountableClosedRange`? On Sep 8, 2017, 12:08 PM -0500, Shawn Erickson , wrote: It would be nice to leverage range support instead of a

Re: [swift-evolution] [Concurrency] async/await + actors

Hi All. A point of clarification in this example: func loadWebResource(_ path: String) async -> Resource func decodeImage(_ r1: Resource, _ r2: Resource) async -> Image func dewarpAndCleanupImage(_ i : Image) async -> Image func processImageData1() async -> Image { let dataResource = await

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

I would very much like to see this implemented in pure Swift, i think it’s only a hundred lines of code to implement anyway. That way, we also have the same deterministic PRNGs across all Swift platforms. We should avoid sticking more and more stuff into Foundation if it’s not necessary for

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

> On Sep 4, 2017, at 11:35 AM, Matthew Johnson via swift-evolution > wrote: > > >> On Sep 4, 2017, at 11:47 AM, T.J. Usiyan > > wrote: >> >> I wasn't arguing for a strictly parallel syntax. I was arguing against

Re: [swift-evolution] [Pitch] DateComponents{Encoding/Decoding}Strategy in JSON{Encoder/Decoder}

Hi Itai, As I told you in my last email that I’m thinking about the ISO 8601 case. After thinking about that, having a discussion in the Swift Evolution and reading your emails, I think it may not worth to add this into Swift Standard Library. I think the use case is not that much so it’s not

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

> On Sep 8, 2017, at 2:17 PM, Robert Widmann wrote: > >> >> On Sep 4, 2017, at 11:35 AM, Matthew Johnson via swift-evolution >> > wrote: >> >> >>> On Sep 4, 2017, at 11:47 AM, T.J. Usiyan

Re: [swift-evolution] [Concurrency] async/await + actors

> On 8 Sep 2017, at 20:34, Kenny Leung via swift-evolution > wrote: > > Hi All. > > A point of clarification in this example: > > func loadWebResource(_ path: String) async -> Resource > func decodeImage(_ r1: Resource, _ r2: Resource) async -> Image > func

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

Huge +1 to stdlib (or even Foundation) random number generator. I’ve worked with random numbers on both Linux and macOS/iOS and have found myself annoyed with the lack of easy random number generators. It seems that implementing a pure Swift RNG would be an obviously good addition to the

Re: [swift-evolution] [Pitch] DateComponents{Encoding/Decoding}Strategy in JSON{Encoder/Decoder}

Hi Pitiphong, Thanks for taking the time and energy to pitch this, too! If we can find a good solution for matching this up with ISO 8601, and we have high demand for this feature, I think it will be worth reconsidering again in the future. Thanks for the input! — Itai On 8 Sep 2017, at

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

> On Sep 8, 2017, at 4:26 PM, Robert Widmann wrote: > >> >> On Sep 8, 2017, at 2:59 PM, Matthew Johnson > > wrote: >> >>> >>> On Sep 8, 2017, at 2:17 PM, Robert Widmann >>

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

> On 8 Sep 2017, at 23:01, Matthew Johnson via swift-evolution > wrote: > > >> On Sep 8, 2017, at 2:30 PM, Ben Cohen via swift-evolution >> > wrote: >> >> Hi Alejandro, >> >> I’m really happy to see

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

> On Sep 8, 2017, at 2:46 PM, Jacob Williams via swift-evolution > wrote: > > What if we did it with something like this: > > protocol RandomGenerator { > associated type T: Numeric // Since numeric types are the only kinds > where we could get a random

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

> On Sep 8, 2017, at 12:46 AM, Haravikk via swift-evolution > wrote: > > >> On 7 Sep 2017, at 22:02, Itai Ferber > > wrote: >> >> protocol Fooable : Equatable { // Equatable is just a simple example >> var myFoo:

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

> On Sep 8, 2017, at 2:30 PM, Ben Cohen via swift-evolution > wrote: > > Hi Alejandro, > > I’m really happy to see someone pick this up. We had suggested some kind of > random support could be a goal for addition to the standard library in Swift > 4 phase 2 but

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

> On Sep 8, 2017, at 2:59 PM, Matthew Johnson wrote: > >> >> On Sep 8, 2017, at 2:17 PM, Robert Widmann > > wrote: >> >>> >>> On Sep 4, 2017, at 11:35 AM, Matthew Johnson via swift-evolution >>>

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

What if we did it with something like this: protocol RandomGenerator { associated type T: Numeric // Since numeric types are the only kinds where we could get a random number? func uniform() -> T // Other random type functions... } Although if we didn’t constrain T to

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

> On Sep 8, 2017, at 12:05 PM, Tony Allevato wrote: > > > > On Fri, Sep 8, 2017 at 9:44 AM Matthew Johnson > wrote: >> On Sep 8, 2017, at 11:32 AM, Tony Allevato >

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

Here is some Swift 3 code that allows simple repeatable repeatable random sequences by conforming to a protocol: https://gist.github.com/jonhull/3655672529f8cf5b2eb248583d2cafb9 I now use a slightly more complicated version of this which allows more complex types (like colors) to be added and

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

On Fri, Sep 8, 2017 at 4:08 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > On Sep 8, 2017, at 12:05 PM, Tony Allevato > wrote: > > > > On Fri, Sep 8, 2017 at 9:44 AM Matthew Johnson > wrote: > >> On Sep 8, 2017,

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

> On Sep 8, 2017, at 8:09 PM, Xiaodi Wu via swift-evolution > wrote: > > This topic has been broached on Swift Evolution previously. It's interesting > to me that Steve Canon is so certain that CSPRNGs are the way to go. I wasn't > aware that hardware CSPRNGs have

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

On Fri, Sep 8, 2017 at 4:00 PM, Itai Ferber via swift-evolution < swift-evolution@swift.org> wrote: > > > On Sep 8, 2017, at 12:46 AM, Haravikk via swift-evolution < > swift-evolution@swift.org> wrote: > > > On 7 Sep 2017, at 22:02, Itai Ferber wrote: > > protocol Fooable :

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

On Fri, Sep 8, 2017 at 7:50 PM, Stephen Canon wrote: > On Sep 8, 2017, at 8:09 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > This topic has been broached on Swift Evolution previously. It's > interesting to me that Steve Canon is so certain that

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

Hey folks! Thanks for all the great feedback and discussion. I really like Tony's suggestion of the opt-in ValueEnumerable protocol. However, I think Kevin is right that it should be a simple array. If we wanted to get fancy, we could implement a custom integer indexed collection that indexed

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

let me summarize why i think deallocate should lose the capacity parameter for now: - up to now, the capacity argument has been poorly, even misleadingly documented. this means it is unlikely that existing users of the API are using it correctly. - deallocate(capacity:) allows for