To answer the question “what problem does this solve?”, I’m thinking of a situation like this - granted, this is a bit artificial, but imagine if there were a very large number of states…)
enum Tristate: Int {
case High = 0
case Low
case Off
mutating func next() {
let nextState = (self.rawValue + 1) % Tristate.count
self = Tristate(rawValue: nextState)!
}
}
I propose adding a read-only ‘count’ property to enum types, that returns the number of cases; modelled on the API for arrays types.
Most discussions of this start with a `count` proposal, proceed to an `allValues` array or something of the sort, and then fizzle out before anyone actually writes a formal proposal. Feel free to break that pattern.
Why does it fizzle out? I've seen many posts on the web from developers
looking for a way to return an array of all values from a Swift enum. The
only decent solution I've seen work for enums that have Integer-type raw
values, a la Nate Cook: How do I get the count of a Swift enum? - Stack Overflow
What I always found interesting was how enums play with Switch statements.
As Switch statements need to be exhaustive, they have the ability to check
to see if all cases of the enum have been explicitly declared (or
implicitly via the 'default' case). This makes me think that extending
there should be a trivial way to add this functionality to enums.
···
On Sun, Jan 17, 2016 at 7:07 AM Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote:
> I propose adding a read-only ‘count’ property to enum types, that
returns the number of cases; modelled on the API for arrays types.
Most discussions of this start with a `count` proposal, proceed to an
`allValues` array or something of the sort, and then fizzle out before
anyone actually writes a formal proposal. Feel free to break that pattern.
Well, there's now a concrete proposal in the thread "Pre-proposal: CaseEnumerable protocol (derived collection of enum cases)", so it seems like we've broken this pattern.
On Tue, Jan 19, 2016 at 5:29 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote:
> Why does it fizzle out?
Well, there's now a concrete proposal in the thread "Pre-proposal:
CaseEnumerable protocol (derived collection of enum cases)", so it seems
like we've broken this pattern.
Woohoo! Thanks for the update - will take a look in there now!
···
On Tue, Jan 19, 2016 at 8:29 PM Brent Royal-Gordon <brent@architechies.com> wrote:
> Why does it fizzle out?
Well, there's now a concrete proposal in the thread "Pre-proposal:
CaseEnumerable protocol (derived collection of enum cases)", so it seems
like we've broken this pattern.
+1 from me as well. Proposed solution works very well. I'd personally
prefer some convenience methods on enum to directly return array/count, but
the solution proposed is more 'Swift'y.
···
On Tue, Jan 19, 2016 at 8:33 PM Jacob Bandes-Storch <jtbandes@gmail.com> wrote:
On Tue, Jan 19, 2016 at 5:29 PM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote:
> Why does it fizzle out?
Well, there's now a concrete proposal in the thread "Pre-proposal:
CaseEnumerable protocol (derived collection of enum cases)", so it seems
like we've broken this pattern.
On 20 Jan 2016, at 02:43, Arthur Ariel Sabintsev <arthur@sabintsev.com> wrote:
+1 from me as well. Proposed solution works very well. I'd personally prefer some convenience methods on enum to directly return array/count, but the solution proposed is more 'Swift'y.
On Tue, Jan 19, 2016 at 5:29 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
> Why does it fizzle out?
Well, there's now a concrete proposal in the thread "Pre-proposal: CaseEnumerable protocol (derived collection of enum cases)", so it seems like we've broken this pattern.
Just a quick note regarding case names... Using string interpolation already does that *if* your enum does *not* conform to CustomStringConvertible. If Swift had a way "undo" protocol conformance, we'd get that for free. Something like:
"\(MyEnum.foo without CustomStringConvertible)" or "\(MyEnum.foo as !CustomStringConvertible)"
- Dave Sweeris
···
On Jan 20, 2016, at 07:47, Martin Crossley via swift-evolution <swift-evolution@swift.org> wrote:
Excellent news!
Sent from my iPhone
On 20 Jan 2016, at 02:43, Arthur Ariel Sabintsev <arthur@sabintsev.com> wrote:
+1 from me as well. Proposed solution works very well. I'd personally prefer some convenience methods on enum to directly return array/count, but the solution proposed is more 'Swift'y.
On Tue, Jan 19, 2016 at 5:29 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
> Why does it fizzle out?
Well, there's now a concrete proposal in the thread "Pre-proposal: CaseEnumerable protocol (derived collection of enum cases)", so it seems like we've broken this pattern.