[SR-6063] KeyedDecodingContainer unnecessarily verbose

[DagAgren]

Previous ID	SR-6063
Radar	None
Original Reporter	@DagAgren
Type	Improvement

Additional Detail from JIRA

Votes	0
Component/s	Standard Library
Labels	Improvement
Assignee	@itaiferber
Priority	Medium

md5: 0fbbda081c8f375951c544eb7669acc1

Issue Description:

The KeyedDecodingContainer.decode() take a type as their argument. This seems redundant, as the return type could easily be used to infer what type is being decoded.

Are there any plans to include versions of decode() that do not need the type to be explicitly specified? It is trivial to write an extension that does this, but it feels like this should be provided by the standard library.

[belkadan]

It's pretty standard to not rely on return type inference for something where the type isn't constrained in any way, because it's too easy to slip up. (For example, assigning to a property with type Int? would pass Int? as the type, which would fail to decode an Int.) Additionally, it would make decoding into a local binding more confusing, since people conventionally write those without type annotations.

This doesn't mean this change can't happen, but it would need to go through the Swift Evolution Process.

cc @itaiferber

[itaiferber]

This was discussed at length on the swift-evolution mailing list a while back. It's something that's possible for us to add in the future via extensions (so I won't close this issue), but there are a variety of cases where explicitly specifying the generic type is necessary (and the canonical way to do this is to pass in a metatype parameter).

Jordan mentions one such case:

// Elsewhere: var myFoo: Int?
// myFoo has to be optional for other reasons, but here we definitely want to decode an Int or fail if we can't.
// If we just decode(.myFoo) and forget to pass in a concrete type, this would silently fail.
self.myFoo = try container.decode(Int.self, forKey: .myFoo)

Another case that comes to mind:

class Foo { ... }
class Bar : Foo { ... }

// Elsewhere: var myFoo: Foo
// The static type of myFoo has to be Foo for other reasons, but here we definitely want to decode a Bar.
self.myFoo = try container.decode(Bar.self, forKey: .myFoo)

As mentioned, it's easy to add extensions to do this if you'd like, e.g.:

extension KeyedDecodingContainer {
    func decode<T : Decodable>(_ key: Key, as type: T.Type = T.self) -> T {
        return self.decode(T.self, forKey: key)
    }
}

so this would have to fall under the same scrutiny that we apply to adding other APIs to the stdlib, i.e.: What is the cost-benefit ratio of adding new API here?

[DagAgren]

These seem like fairly rare cases that, on average, you'd expect people to be aware of anyway, though. It seems a little bit overkill to make the API more verbose and less ergonomic to protect against carelessness in rare cases.