SE-0295: Codable synthesis for enums with associated values

Evolution Proposal Reviews
82

I know the review period is long over, but I’d like to raise an issue that I think hasn’t been mentioned in the review thread or the proposal (apologies if I missed it).

The proposal is intended for enums that have at least one payload case, but it would also apply to enums that have no associated values and are not RawRepresentable.

If accepted, this code, which is currently a compile error because the enum is not RawRepresentable, would become valid:

enum Color: Codable {
  case red
  case yellow
}

I think the proposal text should specifically mention this case. I also think it’s very desirable that a no-payload, non-RawRepresentable enum encode itself in the same way as if it had strings as raw values. That is, the enum above should have the same encoding format as this one:

enum Color2: String, Codable {
  case red
  case yellow
}

If the formats were not the same, many people would forget to make their enums string-backed and be surprised about the encoded data.

Following the existing encoding format for RawRepresentable enums would mean no-payload cases should be encoded as @brentdax suggested, i.e. not nested inside a keyed container. If this isn't possible because the Decoder API doesn't allow it or we decide on a different format, it's a significant drawback for the proposal in my opinion.

1 Like