Add default parameter values to DecodingContainer decode overloads

Evolution Pitches
1

There is probably some reason I don't understand that all of them require a metatype argument.

Can we just give them all a default (i.e. making the beginning of the signatures look like this)?

func decode(_ type: Decodable.Type = Decodable.self

The .selfs are not helpful. Not having them is better.

struct Coatable: Codable {
  let 🥼: Int
  let 🧥: String
}

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

    🥼 = try container.decode(forKey: .🥼)

    let 🧥: String = try container.decode(forKey: .🧥)
    self.🧥 = 🧥
  }
}

This does the job, but not as well as all the individual overloads.

public extension KeyedDecodingContainerProtocol {
  func decode<Decodable: Swift.Decodable>(forKey key: Key) throws -> Decodable {
    try decode(Decodable.self, forKey: key)
  }
}

When subscripts can throw, I think this will be better still…

subscript<Decodable: Swift.Decodable>(
  key: Key,
  type type: Decodable.Type = Decodable.self
) throws -> Decodable {

…but there's still an improvement to be made before that's possible.

2

You don't even need the overload, T.Type = T.self gives you the best of both worlds. As for why it was designed that way, @itaiferber can tell you. Most likely it due to protocol requirements not being able to have default values, and perhaps such an implementation could meet the requirement back then. I also seem to remember some discussion around wanting to avoid confusion. You can implement the overloads yourself and they'll work fine.

And a subscript isn't really appropriate for an action like this, they're more for accessing values.

3

I'm not talking about adding overloads. I'm talking about adding default parameter values. To all of the overloads. That is a lot and I don't want to maintain it. Nobody wants to maintain it! That's why the documentation is the same for every overload. :smile_cat:

4

It'd be a shame that we can only add it to Keyed*Container since it's the only non-protocol (compatibility aside).

5

Adding defaults is not an ABI compatible change, so at most we'd be able to add overloads, but I'm not sure what other impact that may have. I think something like this would be more possible as a larger refactoring of the Codable APIs.

Edit: I take that back, adding a default may be resilient, adding a new parameter with a default is not.