To add to what @ole says, what's happening here is not a bug, but is indeed subtly misleading:
- Enums actually do not currently synthesize
Codable
conformance — see Automatic Codable conformance for enums with associated values that themselves conform to Codable for a bit of background, but at the moment, there's no decided-upon representation of what encoded enums should look like; as such, no implementation is offered - The reason you are getting a default implementation of
Codable
is becauseOptions
isRawRepresentable
with aRawValue
ofString
.RawRepresentable
types whoseRawValue
is aCodable
primitive type (Int
,UInt
,Double
,String
, etc.) get a default implementation based on thatRawValue
; you can see the one forString
- As @ole says, these
RawRepresentable
implementations encode and decode in terms of the underlyingrawValue
, and do so in and out of a single-value encoding/decoding container. That's why your keys aren't used
So indeed, you can either assign the raw values of the enum cases to match the representation you want (if feasible), or keep the values the same but provide your own Codable
implementation to override the default.