[swift-evolution] [Proposal] Enums with stored properties

[Karl]

> My point is that, IMO, this is all I want. Thus what I’m implying is that there’s probably not any ABI impact to (IMO) “fix” enums with associated values, and so I don’t know why this discussion keeps going on and veering into (what seems to me to be) overly complex territory when many of us just want a nicer way to express cases likes these - not a whole new enum model that has to break everything.

To be fair, the title is "Enums with stored properties” and the OP insists it is not just syntactic sugar.

I think we all want better syntax for working with enums. They are groups of related values, so surely they have many common properties, but the barrier between enum cases in the language is sometimes far stronger than the barrier between them semantically.

Maybe some kind of actual stored properties would be nice. Not like the “RectSize” example in this thread, where the values were all constants, but like the “FileError” example, where every case has a URL associated value. For example:

enum Something {
    var timeTaken : TimeInterval

    case oneThing(Int)
    case anotherThing(Double)
    case yetAnother(Bool)
}

is equivalent to:

enum Something {
    case oneThing(Int, TimeInterval)
    case anotherThing(Double, TimeInterval)
    case yetAnother(Bool, TimeInterval)
}

Since we know all payloads contain a TimeInterval and you didn’t specify a layout, we could lay them out in a predictable position for faster access. The compiler could probably do that anyway, even if you did specify an explicit tuple, but doesn’t today AFAIK. Maybe I’ll look at implementing that - we could maybe get away with it now, but it wouldn’t be worth the hassle once we have a stable ABI.