More generally, I'm against the proposal as written. I recognize that there's no obvious format that will satisfy all requirements, but I do think missing code synthesis for enums with payload is a significant gap in the language that Swift should eventually have an answer for. I listed one example in the previous post where I think the synthesis rules listed in the proposal are not the right defaults. I also agree with most of the other suggested changes made by @brentdax and others.
I remember there was a similar discussion about the encoding format used for Range’s Codable conformance (unkeyed vs. keyed container). SE-0239 eventually settled on using an unkeyed container. @tkremenek’s acceptance post for SE-0239 may be relevant to this discussion (emphasis mine):
For
Rangetypes, the Core Team concluded from the review conversation that an unkeyed container representation seems like a reasonable default, but also recognized from the discussion on this thread that there are cases where a keyed representation is preferred. What this review thread further illustrated is the need to makeCodablemore flexible to provide the encoding customizations needed to service different tasks. There is no set of defaults for encoding that will satisfy every use-case. Some use-cases will prioritize serialization performance over human readability, and quite often the inverse. The Core Team would like to encourage the community to channel the energy that appeared in this thread to discussing general enhancements toCodeableto make it more flexible and amendable to serving more use-cases more easily, and @itaiferber has initiated a thread to do just that .
@drexin Thank you for work on this!