Open jdmcd opened 2 years ago
The issue is further exacerbated by Swift generating incorrect decoding logic when it encounters property wrappers with optional wrapped values, always decoding the corresponding coding key unconditionally. As most encoders encode nothing for nil values, and decoders verify the presence of a given key when asked to decode it regardless of whether it represents a nested container, a missing key error is inevitably thrown if the original encoded value was nil. The error occurs in the context of the container before the property wrapper’s own Codable conformance can ever come into play, with the various possible workarounds each having nontrivial drawbacks.
This matters for the problem described herein because if the wrappers were correctly decoded, there would be no need for the type erasure in the first place.
Additional note: As with some other outstanding concerns around property wrappers, the formalization of API vs. implementation detail property wrappers in SE-0293 theoretically cleared the path to a solution, but there was no follow up.
The
anyValueType
eraser inFields+Codable
is coalescing the double-optional of OptionalParent.Value to a single optional, causing it to improperly decode when passed around via Codable.