Read Only Property Wrappers in Swift

Property Wrappers are one of my favorite additions to Swift 5.1. If you haven’t read about them before, check out the proposal and this NSHipster article. They are very similar to Kotlin’s delegated properties, but the syntax is similar to Java’s annotations.

It may not be readily apparent, but one really nice feature of Property Wrappers is you can create “read only” property wrappers. These are properties that you can read from, but not write.

What would be a real life example of this? An example of this use might be a globally accessible constant key-value store. One problem with globally accessible stores is that you don’t want the underlying data modified. Ideally you would only allow it to be set once:

This could be handled with a singleton and a non-reentrant function.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

class GlobalDataStore {
    enum DataStoreError: Error {
        case alreadyStarted
    }

    private var data: [String: Any]
    private var hasStarted = false

    private init() {
        data = [:]
    }

    static let shared = GlobalDataStore()

    func start(data: [String: Any]) throws {
        guard hasStarted == false else {
            throw DataStoreError.alreadyStarted
        }

        hasStarted = true
        self.data = data
    }

    subscript(key: String) -> Any? {
        data[key]
    }
}

We only allow starting this function once. This works fine:

1
2
3
4
5

do {
    try GlobalDataStore.shared.start(data: ["USER_ID" : UUID()])
} catch {
    print("error: \(error)")
}

But If I try to call start multiple times:

1
2
3
4
5
6

do {
    try GlobalDataStore.shared.start(data: ["USER_ID" : UUID()])
    try GlobalDataStore.shared.start(data: ["USER_ID" : UUID()])
} catch {
    print("error: \(error)")
}

I get an error that it’s already started: error: alreadyStarted

We can then declare a property wrapper for this data store:

1
2
3
4
5
6
7
8
9

@propertyWrapper
struct GlobalData<T> {
    let key: String
    var wrappedValue: T? {
        get {
            GlobalDataStore.shared[key]
        }
    }
}

What’s interesting here is that I’m not declaring the setter for the wrapped value. Only the getter. I can even remove the get block because swift implicitly interprets a block definition as a get. This makes a very nice and concise property wrapper:

1
2
3
4
5

@propertyWrapper
struct GlobalData<T> {
    let key: String
    var wrappedValue: T? { GlobalDataStore.shared[key] }
}

Here is how to use the property wrapper in another class:

1
2
3
4
5
6
7

struct ContentView: View {
    @GlobalData(key: “USER_ID”) var userID: UUID?

    var body: some View {
        Text(userID?.uuidString ?? “No User ID Set”)
    }
}

This will get the value which was previously set globally. If the value was not set, then it’ll just return nil.

What’s more interesting is that I can’t modify the variable, even though it’s declared as a var. This is because the property wrapper has no setter method defined, only a getter. If I try to set it, I’ll get a compiler error:

1
2
3

func doSomething() {
    userID = UUID()  // ERROR: Cannot assign to property: ‘userID’ is a get-only property
}

This gives us a nice clean interface to define a global key-value store that can only be set once, but referenced throughout the app. The property wrapper gives is easy access to getting value, visibility to where the value is coming from, and prevents us from misusing our interface.

It’s even safer than you think!

What happens if I declare the property as a non-optional?

1
2
3
4
5
6
7

struct ContentView: View {
    @GlobalData(key: “USER_ID”) var userID: UUID

    var body: some View {
        Text(userID.uuidString)
    }
}

I get a compiler error telling me that I’m using an optional type that needs to be unwrapped. Complete with a fixit to unwrap it:

Even though I declared my type as a non-optional, the type returned is an optional. This is because I’m forcing the wrapped value to always return an optional. Command-clicking on the variable confirms this:

Final Thoughts

Property wrappers are a relatively simple construct, but digging into them leads to some pretty safe and intuitive behavior. While a pretty and powerful safe abstraction, one danger with this syntactic abstraction is over-using them to the point where it becomes hard to reason about code (custom operators are another example of this). All property wrappers should be well documented and include any caveats. Finally, if the property isn’t being stored on the class itself (like in my example), it should be clearly stated where the object is stored.