> On Dec 21, 2015, at 12:09 PM, Erica Sadun via swift-evolution
> <[email protected]> wrote:
>
> My wild aspirations in a nutshell:
>
> Core enums: Any enum that's created without raw or associated values, e.g.
> enum MyEnum {case This, That, Whatever, Etc}, can (and should) be
> Array<Self> representable. This would add intrinsic ordering and raw value
> construction starting with 0, up to count - 1. End-devs could use the
> ordering or not use the ordering, but it would be possible to convert to bit
> representation (1 << this.rawValue), support iteration through the
> enumeration, introduce ranges for switches, etc. A massive improvement.
>
> Raw value enums: Any enum that uses raw values, e.g. enum ForExample: String
> {case Hello = "hello", There = "there"} should be representable as Set<T>
>
> Associated type enums: all bets are off
There's only one kind of enum fundamentally, and I think we should make for
more continuity between different instances of enum rather than less. Any type
with a reasonably finite number of states ought to be able to support a
`values` collection. If it happens to have a RawRepresentable conformance,
mapping from values to rawValues is easy, and could be provided by a protocol
extension on ValueEnumerable where Self: RawRepresentable. Enums with
associated values that are themselves ValueEnumerable could enumerate all the
values of the associated value, so something like this:
enum Foo: ValueEnumerable { case A, B, C }
enum Bar: ValueEnumerable { case X(Foo), Y(Foo) }
would give you `.X(.A)`, `.X(.B)`, `.X(.C)`, etc. (You could also derive
ValueEnumerable for structs by walking the cartesian product of the stored
properties' values, but I don't know if that's really useful.)
-Joe_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
