> 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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
