Why Decodable.init(from:) did not follow API Design Guidelines?

As API Design Guidelines suggested:

The first argument to initializer and factory methods calls should not form a phrase starting with the base name, e.g. x.makeWidget(cogCount: 47)

cc @itaiferber

The implied alternative initializer signature, if following other API Design Guidelines, would presumably be something akin to x.makeWidget(withCogCount: 47) and instead the goal is to drop the "with" preposition.

Another initializer guideline is to drop a label (ie. _) if the type being initialized is a lossless conversion from the provided value. Conversely, if it is not a conversion, or if it is a conversion with data loss (which we could have with Codable), then a label should be provided.

So we're in a middle ground where we need to communicate in our initializer that we need an object temporarily to read values to establish our current state.

At this point, we're at the point of just needing to say "You can initialize this Decodable from an instance of Decoder and only the information necessary will be read from it. Thus, the init(from:) signature.

If you saw an initializer with just Decodable(decoder: JSONDecoder()) (or if the passed value was named decoder) it would:

  1. Have ambiguous meaning unless you fully understood the Codable feature set, and how this implementation works with it. Does it store a reference to the decoder, or just use it?
  2. It has a non-"Swifty" interface that makes it awkward to work with.
2 Likes
Terms of Service

Privacy Policy

Cookie Policy