Why do enums have computed properties but not stored properties in Swift?

I'm not sure exactly how to explain it… A computed property of an enum acts on the characteristics of the enum's value, whereas a computed or stored property of an object or struct acts on information within the object or struct itself. Enums don't have the "within itself" part; they're a little like those undividable subatomic particles. Does that make sense to you?

Thanks for the response !!!

As you concluded that "Enums don't have the 'within itself' part" , could you please give technical reson why enums allow typed properties then, Please have a look to the below code :

enum Climate {

static var abc:String? /// Here type stored property is allowed

case India

case America

case Africa

case Australia

}

Static properties are different from a property on an instance of a object or struct or enum. With objects and structs, you have discrete instances of those entities. With enums, you don't, but you still have the type itself. Think of it this way: the type is kind of like a cookie cutter, which obviously is a real object. Objects and structs are like cookies made using the cutter: each one is also a real and independent object, and you can decorate each one differently (instance properties—both stored and computed). You can also bend the cookie cutter into a different shape (static properties).

With enums, all you have is the cookie cutter. You can take photographs of it and share them around, but that's it. There are no "real" instances of an enum. You can still bend the cookie cutter around (static properties), but you have no cookies to decorate. However, you can imagine what the cookies would look like and make plans based on it. Those are get-only computed properties, which you are allowed to use in an enum.

Sorry if this is a little hard to explain, but I hope I'm making things a little clearer for you 🙂

IMO the purpose of an enum is to store data that varies by case (in type theoretical terms, it’s a sum type). In it’s simplest form this is just the cases of the enum.

enum State {
    case opening
    case connected
    case closed
}

However, in a more complex case you can have associated values.

enum State {
    case opening(connection: TCPConnection)
    case connected(connection: TCPConnection, bytesSent: Int, bytesReceived: Int)
    case closed
}

In this context the

connection

.closed

bytesSent

bytesReceived

.opening

Now, imagine you have a value that makes sense in all states. You could model this like this:

enum State {
    case opening(hostName: String, connection: TCPConnection)
    case connected(hostName: String, connection: TCPConnection, bytesSent: Int, bytesReceived: Int)
    case closed(hostName: String, bytesSent: Int, bytesReceived: Int)
}

but that’s kinda silly because

hostName

enum State {
    let hostName: String
    case opening(connection: TCPConnection)
    case connected(connection: TCPConnection, bytesSent: Int, bytesReceived: Int)
    case closed(bytesSent: Int, bytesReceived: Int)
}

but, again, that runs counter to the concept of an enum, where the data is supposed to vary by the case. The correct way to model it is like this:

struct Connection {
    let hostName: String
    enum State {
        case opening(connection: TCPConnection)
        case connected(connection: TCPConnection, bytesSent: Int, bytesReceived: Int)
        case closed(bytesSent: Int, bytesReceived: Int)
    }
}

That is, use each construct for the purpose for which it was intended:

• structs for data that’s present in all cases

• enums for data that varies by case

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"