[swift-evolution] List of all Enum values (for simple enums)

Jacob Bandes-Storch jtbandes at gmail.com
Mon Dec 21 14:27:14 CST 2015


Bumping this thread because it's relevant to recent discussions in
"Proposal: Enum 'count' functionality". To summarize points so far:

Minimum and particularly maximum rawValues would be useful for
integer-typed enums.

For NS_ENUM/NS_OPTIONS and Swift enums without associated values, something
like "allValues" would be useful.

This functionality could be added at the request of the user, by deriving a
protocol such as "enum Foo: ValueEnumerable".

Brent (in this thread) and Joe (in the other thread) have proposed
Cartesian products for nested "enumerable" enums:

        enum Foo {
>                 case Alice, Bob
>         }
>         enum Bar {
>                 case Charlie (Foo), Eve (Foo, Foo)
>         }
>         Bar.allValues   // => [ .Charlie(.Alice), .Charlie(.Bob),
> .Eve(.Alice, .Alice), .Eve(.Alice, .Bob), .Eve(.Bob, .Alice), .Eve(.Bob,
> .Bob) ]
>


Barring full Cartesian product support, would it be useful to have some
form of "allValues" for enums with associated values, or is the ability to
do "if case let" sufficient to discriminate them?

Jacob Bandes-Storch

On Fri, Dec 11, 2015 at 5:49 PM, Zef Houssney via swift-evolution <
swift-evolution at swift.org> wrote:

> Yeah thank you —I did mean the constructor, didn’t think of that
> terminology :)
>
> I recognize that it’s not totally ideal but I do still see that as being
> useful. Here’s an example of how you could use that. For cases that have
> the same signature, it’s less ideal but still totally workable as far as I
> can see.
>
> Also with this approach you could fairly easily create the data structure
> you suggested yourself.
>
>
> enum Foo {
>     case Plain
>     case AssociatedSimple(String)
>     case AssociatedComplex(String, Int)
>     case AssociatedSimpleCopy(String)
>
>     static var cases: [Any] {
>         return [
>             Plain,
>             AssociatedSimple,
>             AssociatedComplex,
>             AssociatedSimpleCopy,
>         ]
>     }
> }
> let cases = Foo.cases
>
> cases[0] is Foo // true
> cases[1] is Foo // false
> cases[2] is Foo // false
>
> cases[0] is (String) -> Foo // false
> cases[1] is (String) -> Foo // true
> cases[2] is (String) -> Foo // false
>
> cases[0] is (String, Int) -> Foo // false
> cases[1] is (String, Int) -> Foo // false
> cases[2] is (String, Int) -> Foo // true
> if let simple = cases[1] as? (String) -> Foo {
>     let created = simple("some value")
>
>     switch created {
>     case .AssociatedSimple:
>         // we'd hit this:
>         print("Simple")
>     case .AssociatedSimpleCopy:
>         // here if you didn't want the original "some value"
>         // you could create the enum with a different value
>         print("Simple Copy")
>     default:
>         print("Something else")
>     }
> }
>
>
> I don’t love that it’s using [Any] here, but I don’t know if it’s possible
> to represent that `() -> Foo` where the methods passed can be dynamic…
> didn’t seem to be with what I was trying. Related to that, it might make
> more sense to have the “Plain” value above represented as `() -> Foo`
> instead of simply `Foo`.
>
>
>
>
> On Dec 11, 2015, at 5:43 PM, Brent Royal-Gordon <brent at architechies.com>
> wrote:
>
> However, I do have a suggestion that’s different from what Brent
> suggested, which is that instead of returning actual enum values, I could
> see returning the functions associated with them as being potentially
> useful. I can show an example of what this might look like if anyone is
> interested.
>
>
> Interesting. The problem I see with this is that, if by “the functions
> associated with them” you mean their constructors, each constructor would
> have a different set of parameters. To distinguish between them, you would
> probably need…an enum.
>
> On the other hand, if you mean “functions testing an instance of the enum
> against that case, and returning true if it matches”, that’s a more
> interesting possibility.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151221/5eca706b/attachment.html>


More information about the swift-evolution mailing list