More granular encoding / decoding strategies (Dates and more)

[itaiferber]

Hi Matthew, a few comments here:

@anandabits

This behavior is not always acceptable. When it is not acceptable a manual implementation of Codable is necessary. If a team decides consistent encoding / decoding to JSON of all model types is important Codable synthesis is no longer possible for any model types that store Date values.

More importantly, the reality is that some APIs return dates in more than one format in different parts of a response. A single encoding / decoding strategy for an entire payload is not always sufficient.

This steep cliff of language support is very unfortunate. It would be nice if the encoding / decoding strategy could be specified at the property level (and perhaps the type level if a type has several dates that should all be encoded / decoded using the same strategy).

You're in luck! This is exactly what the JSONDecoder.DateDecodingStrategy.custom strategy was written for. You get a Decoder (which has a codingPath for you to inspect) and can make a decision on a per-property basis on how to decode that date.

Even with the .formatted strategy, you can always pass in a DateFormatter subclass which tries multiple date formats that you can decide on supporting ahead of time.

[This is, of course, one approach to solving this per-property behavior, which could also be served by the discussion over at Excluding properties from automatic Codable - #7 by anon31136981 that @ahti links to.]

@anandabits

A related use case I have encountered is that a type in a framework which should not be initializable outside the framework cannot conform to Decodable. Types like this defeat Decodable synthesis for all types that need to store them because init(from:) would be public. Unfortunately, synthesis is defeated even when an internal an initializer which takes a Decodable value is available. It would be nice if it were possible to specify a custom decoding strategy (i.e. expression) for any property, although I'm not sure what the best way to express that would be.

This isn't unique to Decodable, really — if you have a protocol which requires an init and a type which cannot vend such inits, well, there isn't much you can do.

What is entirely possible is for you to write a wrapper type for the external type you don't own and conform that to Decodable. This is the recommended way to conform others' types to Decodable, too, without conflicting with any Decodable definition they might want to provide later on.