Draft Proposal: count property for enum types


(Martin Crossley) #1

I’m going to apologise if this has already been proposed a million times before, but I can’t find a way to search the list. I’m a novice here guys :slight_smile:

I propose adding a read-only ‘count’ property to enum types, that returns the number of cases; modelled on the API for arrays types.

This has been discussed previously in user communities (e.g. see http://stackoverflow.com/questions/27094878/how-do-i-get-the-count-of-a-swift-enum) but it seems to me the proposed solutions are a little complex and inelegant.

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)!
    }
}

thanks, Martin


(Brent Royal-Gordon) #2

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.

···

--
Brent Royal-Gordon
Architechies


(Arthur Ariel Sabintsev) #3

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: http://stackoverflow.com/a/27094913/814861

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.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Best,

Arthur / Sabintsev.com


(Brent Royal-Gordon) #4

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.

···

--
Brent Royal-Gordon
Architechies


(Jacob Bandes-Storch) #5

You can see the latest proposal draft at
https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/0000-derived-collection-of-enum-cases.md

And the discussion in this thread:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006876.html

Jacob Bandes-Storch

···

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.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Arthur Ariel Sabintsev) #6

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.

--
Brent Royal-Gordon
Architechies

--

Best,

Arthur / Sabintsev.com


(Arthur Ariel Sabintsev) #7

+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:

You can see the latest proposal draft at
https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/0000-derived-collection-of-enum-cases.md

And the discussion in this thread:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006876.html

Jacob Bandes-Storch

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.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--

Best,

Arthur / Sabintsev.com


(Martin Crossley) #8

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 8:33 PM Jacob Bandes-Storch <jtbandes@gmail.com> wrote:
You can see the latest proposal draft at https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/0000-derived-collection-of-enum-cases.md

And the discussion in this thread: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006876.html

Jacob Bandes-Storch

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.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Best,

Arthur / Sabintsev.com


(David Sweeris) #9

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 8:33 PM Jacob Bandes-Storch <jtbandes@gmail.com> wrote:
You can see the latest proposal draft at https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/0000-derived-collection-of-enum-cases.md

And the discussion in this thread: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006876.html

Jacob Bandes-Storch

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.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Best,

Arthur / Sabintsev.com

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution