Exempt from the strategy configured on the JSONEncoder / JSONDecoder yes, but not only that. A simple exemption would probably imply the behavior of deferredToDate (what else would it do?). Instead, I want to be able to actually specify an encoding / decoding strategy for synthesis to use with in the implementation for a specific property.
This is part of the reason why I believe the current language support is insufficient. Opting out of the "dynamic" encoding strategy for a type and into a "static" encoding strategy for each property is much more work. Language support is absent and requires a manual implementation. Since dates are an extremely primitive type this can push a team towards a custom synthesis solution. This really feels like an area where the language support is letting us down.
Yes. Think of a model designed in accordance with a json API spec.
This is an unnecessarily fragile API contract. I would like to avoid that fragility. Further, as I mentioned earlier, a global date encoding / decoding strategy is not always sufficient. Yes, we can write this boilerplate manually or generate code using Sourcery (or something else). It still feels like the language support is letting us down here. Unfortunately, dates are a source of much essential complexity and encoding / decoding is not an exception to that.
One man's flexibility is another man's limitation. It's a matter of perspective. In this case, there is no way to use synthesis if you want the consistent behavior other types get. There is no way to say "ignore the dynamic decoding strategy". You have to write a manual Decodable conformance for all types that store a Date to do this. Further, the encoding strategies exist for a reason. Simply suppressing the dynamic strategy isn't enough. We need to be able to specify a static strategy to get have a consistent and correct implementation (correct according to a specific API spec).
I assume you mean init(from:) rather than encode(to:). If this were more of an edge case I would agree. However, Date is a very fundamental type which is stored pervasively by model types. In practice it means that if storing a date requires abandoning synthesis then an alternate synthesis solution is necessary. I think it's unfortunate to be pushed away from language support so easily by a type as primitive as Date.
I'm not looking to use synthesis with a type that doesn't conform. It's precisely the opposite. I'm looking to use synthesis with a type that does conform, but has a stored property that does not conform publicly but provides the same interface internally. The motivation for this is to avoid vending any initializers for opaque token types outside of the framework.
As I think about this further, I realize that we may not need to vend Codable conformances for the model types that store them either. Using private types for encoding / decoding might be a better solution. It would require additional boilerplate but we can generate that with a tool like Sourcery.
I wonder how common the requirement to encode / decode a type within the declaring module while not exposing that behavior publicly is...