The interface for the KeyedDecodingContainer protocol declares a bunch of requirements like such:
func decode(_ type: Bool.Type, forKey key: Self.Key) throws -> Bool
func decode(_ type: String.Type, forKey key: Self.Key) throws -> String
func decode(_ type: Double.Type, forKey key: Self.Key) throws -> Double
// etc.
As well as a generic one:
func decode<T>(_ type: T.Type, forKey key: Self.Key) throws -> T where T : Decodable
Is that done for performance reasons?
I have implemented a return-type-aware generic extension on KeyedDecodingContainer which always defers to the aforementioned generic implementation:
func decode<Value: Decodable>(
type: Value.Type = Value.self,
_ key: Key
) throws -> Value {
try decode(type, forKey: key)
}
Which allows me to decode anything in the following way:
self.myValue = container.decode(.myValue)
// instead of
self.myValue = container.decode(String.self, forKey: .myValue)
Now, this works fine and all, but upon submitting this extension for code review, one of my colleague raised concerns for defaulting to calling only the generic implementation rather than the statically-typed one (where applicable).
So, my question is, are these concerns valid?
