Separate Decodable and Encodable?

[lordzsolt]

Question

What are the options and thoughts on adding separate Decodable / Encodable support?

Problem

With the current implementation, everything relies on T: Codable.

So for example, the following code will not compile, because @DefaultEmptyArray requires ResponseObject to confirm to Encodable as well.

struct NetworkResponse: Decodable {
     @DefaultEmptyArray var someArray: [ResponseObject]
}

struct ResponseObject: Decodable {
    var age: Int
}

But I only care that NetworkResponse be Decodable, I don't need Encodable as well.

In order to make it compile. I need to conform/implement Encodable on ResponseObject. It's trivial of course for the current ResponseObject, but when the object is more complex and uses a custom decoder initializer, I'm left with 2 bad options:

• Spend time implementing the correct Encodable implementation, which will never be used
• Leave a black/throwing implementation of the encode(into:) method, but then I lose compile time guarantee (which is the whole reason I'm using BetterCodable, so I don't have to write a bunch of useless guards)

Solutions

• Ideal solution would be that DefaultCodable<Strategy<T>> would only require T to confirm to what the parent requires. In this case NetworkResponse only requires Decodable, so ResponseObject should only need Decodable.
  • However, I'm fairly certain there's no way to get parent types of a type (since ResponseObject could be used in 2 places, one requiring Decodable, the other one requiring Encodable)
• The next solution would be to add 2 extra types for each property wrapper: DefaultDecodableEmptyArray etc. etc.
• I don't know if there's anything else :\

[marksands]

💯 I will see what I can do.

[entropious]

Hi. Any progress on this? I have the same problem with LossyArray. Don't know why T is restricted to Codable in current implementation. If LossyArray is implemented like this, it will support both Codable and Decodable.

@propertyWrapper
public struct LossyArray<T: Decodable>: Decodable {
    private struct AnyDecodableValue: Decodable {}
    private struct LossyDecodableValue<Value: Decodable>: Decodable {
        let value: Value

        public init(from decoder: Decoder) throws {
            let container = try decoder.singleValueContainer()
            value = try container.decode(Value.self)
        }
    }

    public var wrappedValue: [T]

    public init(wrappedValue: [T]) {
        self.wrappedValue = wrappedValue
    }

    public init(from decoder: Decoder) throws {
        var container = try decoder.unkeyedContainer()

        var elements: [T] = []
        while !container.isAtEnd {
            do {
                let value = try container.decode(LossyDecodableValue<T>.self).value
                elements.append(value)
            } catch {
                _ = try? container.decode(AnyDecodableValue.self)
            }
        }

        self.wrappedValue = elements
    }

}

[lordzsolt]

Don't know why T is restricted to Codable in current implementation.

Answering just this part. @LossyArray supports encoding as well, which your code doesn't.

Some people might want that feature.

[yonaskolb]

Keen to see this too. I think this should be possible to implement with extensions instead similar to how Equatable and Hashable are handled

extension DefaultCodable: Decodable where Default.DefaultValue: Decodable {
...
 }
extension DefaultCodable: Encodable where Default.DefaultValue: Encodable {
...
 }

[yonaskolb]

PR here https://github.com/marksands/BetterCodable/pull/38