Perhaps if enums were automatically indexed by the compiler for the order of the case declerations?
enum Food {
case Fruit
case Vegetable
case Meat
}
Food.Fruit.index == 0
Food.Vegetable.index == 1
Food.Meat.index == 2
3. Re: Proposal: Enum 'count' functionality (Joe Groff)
Message: 3
···
Date: Tue, 22 Dec 2015 07:24:37 -0800
From: Joe Groff <jgroff@apple.com>
To: Zef Houssney <zefmail@gmail.com>
Cc: Swift Evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] Proposal: Enum 'count' functionality
Message-ID: <7BA6F3E4-1053-4EBB-BAEB-DF5D00A816BC@apple.com>
Content-Type: text/plain; charset=utf-8
On Dec 21, 2015, at 10:33 PM, Zef Houssney <zefmail@gmail.com> wrote:
I agree with Stephen Celis that the best names for this (yet) are definitely `cases` and optionally `rawValues` if the cases are RawRepresentable.
Regarding handling cases with associated values where some of those values are other enums, it seems odd to me to try to return every variation of each case. I can’t picture how that would work sanely when there are multiple associated values, such as a case like `MyCase(String, SomeEnum)`. Therefore I prefer the idea of having the array contain the constructor for cases with associated values. The main problem I see here is that the type system (as far as I know) can’t fully represent that type of thing, but I think it’s still potentially valuable. Related to this I’m putting together a separate proposal that explores a bit more on why I believe the enum constructor to be valuable, though that’s in a bit of a different context.
Generating a list of values for MyCase(String, SomeEnum) wouldn't make sense because there are an infinite number of Strings, so Strings don't make sense as a value-enumerable type. However, you could have a mostly-flat enum that uses subenums for organization:
enum Food {
enum Fruit {
case Apple, Banana, BellPepper
}
case fruit(Fruit)
enum Meat {
case Beef, Pork, Venison
}
case meat(Meat)
}
In many C family code bases it's common to group related enums by order, even if there's otherwise no intrinsic order among the elements. Preserving the structure of the cases in the type system makes them easier to understand and work with in pattern-matching, since you can handle all fruits by matching `.fruit(_)` instead of having to maintain `food >= FirstFruit && foo <= LastFruit` ranges. For these kinds of enums, recursively generating the associated values is still useful.
-Joe
I shared these thoughts in a bit more detail here a couple weeks ago, with some followup in the next two messages:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001864.html
Zef
On Dec 21, 2015, at 3:58 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
That would be okay too. Thank you, Santa Joe.
-- E, who hopes she was on the nice list.
On Dec 21, 2015, at 3:56 PM, Joe Groff <jgroff@apple.com> wrote:
On Dec 21, 2015, at 12:24 PM, Erica Sadun <erica@ericasadun.com> wrote:
I could be satisfied by such an approach. I could even be more satisfied if
enum Foo: ValueEnumerable { case A, B, C }
were also essentially an alias for
enum Foo: Int, ValueEnumerable { case A=0, B, C }
:)
If the value collection were sufficiently capable, you wouldn't necessarily need an implicit Int raw value; you could do `allValues.indexOf(.A)` to get the index for a case.
-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
------------------------------
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
End of swift-evolution Digest, Vol 1, Issue 227
***********************************************