SE--0295: Codable synthesis for enums with associated values (third review)

[George]

@Joseph_Heck

While I understand the points that @sveinhal makes, I think the value to the community is quite large, and (as I understand it) the synthesis doesn't prevent or make it any more difficult for you to provide your own custom decoders to match serialized formats from external systems and libraries.

To clarify, automatic synthesis does not prevent using custom decoding and encoding methods, but it does effectively prevent (or makes it much more difficult for) us from ever introducing a different default or behavior and as such I don't think simply adding value is a high enough bar for acceptance.

@Morten_Bek_Ditlevsen

This could mean that with a bit of extra synthesized annotation, the Encoder/Decoder might actually be able to transform the verbose structure to and from a flattened one.

This is similar to the idea I presented here: New {De,En}codingContainer types to support enums with associated types (and tuples). The benefit of a new container type vs translating via a custom encoder/decoder is that you maintain even more information about the structure of the types being coded (for instance, whether or not "_0" was an explicit label or generated for an unlabeled argument). Implementing this would be a bit more work, but doable and I'm happy to work on the Swift parts if someone can help me through the updates needed to the compiler.