Add default parameter values to DecodingContainer decode overloads

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.

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.

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:

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

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.