Thank you for your reply!
Yes, they have assumptions about the payload structure. However, sometimes it differs from built-in structure provided by Swift standard library, like the example of
I agree. Not only
they have built-in assumptions about how their types are represented
CGPoint . Dates and Data specifically because they are ... likely to have the same representation across your entire payload
Date and Data , but also all types are likely to have same representation across entire payload. The types indicate their only one representation by conforming to Codable . The current problem is that, when it differs from assumption, there is no way to adopt "really" assumed format instead of built-in format. So I realized that introducing strategies is not the best way for my motivation. A better way is to - remove built-in
Codableconformance from some types (Data,Date,CGPointand more). - let developers define their own
extension Foo: Codableto conform their "real" format.