Swift custom decodable initializer without CodingKeys

Question

Let's say I have the following decodable struct as an example illustrating what I'm trying to do:

struct Object: Decodable {
    var id: String
    var name: String
}

and this JSON:

[
    {
        "id": "a",
        "name": "test"
    },
    {
        "id": "b",
        "name": null
    }
]

Notice that the name property can be null sometimes. This would mostly work fine like it is since the json keys match the struct property names, so I don't need a CodingKey enum, but the name property can be null sometimes. However, instead of making name optional, I want to substitute a default string, so I need a custom initializer:

struct Object: Decodable {
    var id: String
    var name: String

    init(from decoder: Decoder) throws {
        ...
        self.name = <value from decoder> ?? "default name"
        ...
    }
}

But this requires a CodingKey object. I'm using the default keys. Do I need a CodingKey enum as well now? Even though all my keys match up? Or is there a way to have a custom Decodable initializer using just the keys as they are?

Is there maybe some sort of default container I can use?

let container = try decoder.container(keyedBy: <defaultContainer???>)

I tried using both of these variants, but neither worked:

let container = try decoder.singleValueContainer()

let container = try decoder.unkeyedContainer()

How can I have a custom Decodable intializer but also use the default keys?

Answer 1

The issue is that CodingKeys is only automatically generated for you if didn’t fully manually conform to the relevant protocols. (This is very familiar for Objective-C developers, where a property’s backing ivar would not be automatically synthesized if you manually implemented all the relevant accessor methods.)

So, in the following scenarios, the CodingKeys is not created automatically for you:

1. You adopt only Decodable and implemented your own init(from:);

2. You adopt only Encodable and implemented your own encode(to:); or

3. You adopt both Encodable and Decodable (or just to Codable) and implemented your own init(from:) and encode(to:).

So your case falls within the first scenario, above.

It has been suggested that you can get around your conundrum by adopting Codable, even though you’ve only implemented init(from:) and presumably don’t plan on ever using the Encodable behavior. In effect, that is relying upon a side effect of a protocol you don’t plan on really using.

It doesn’t really matter too much, and adopting Codable works, but it might be considered to be “more correct” to go ahead and define your CodingKeys, rather than relying on the unimplemented Encodable side-effect:

struct Object: Decodable {
    var id: String
    var name: String

    enum CodingKeys: String, CodingKey {
        case id, name
    }

    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)

        id = try container.decode(String.self, forKey: .id)
        name = (try? container.decode(String.self, forKey: .name)) ?? "Default Value"
    }
}