> On Jul 3, 2016, at 6:36 PM, Gabriel Lanata via swift-evolution > <[email protected]> wrote: > > Hello, this has been proposed multiple times before in different ways.
It has indeed. Unfortunately, for various reasons it did not get into review in time, and Swift 3 is basically closed to additive features at this point. Our last pull request to get it reviewed has now been tagged "out of scope for current release". <https://github.com/apple/swift-evolution/pull/114> > The proposed solution is to implement a native `.cases` static var for all > enumerations without associated values. That was one of many things we discussed in previous threads. `cases` isn't good because the natural variable you'd want to use in a `for` loop is `case`: for case in PokemonType.cases { … } And also because other types which aren't technically enums, such as `Bool`, may want to expose their "cases" through the same mechanism. From the proposal: > The resulting areay of cases are ordered in the way they appear in the source > code. Here's one of the sticking points: Should this actually be an array, or should it be some other kind of collection? An array takes up space to store its elements, and for many enums there's no actual reason it needs to. Using a custom collection instead could save memory. > I believe this behaviour should be natively available to all enums. There is > no reason to require that enums conform to the protocol if this behaviour > could be used in all of them. In previous discussions, the core team specifically asked that this be opt-in so that types which don't want it don't need to "pay" for it. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
