> 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 

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.
swift-evolution mailing list

Reply via email to