Using RawRepresentable String and Int keys for Codable Dictionaries

[itaiferber]

For reference, this is SR-7788 [and was brought up way back when in JSON Encoding / Decoding weird encoding of dictionary with enum values]

@Morten_Bek_Ditlevsen

I have looked at stdlib/public/core/Codable.swift.gyb to try and see if I could extend the Dictionary conformance to Encodable and Decodable to be able to use RawRepresentable keys where the RawValue is either String or Int.

Unfortunatly I have failed to implement this since RawRepresenable can only be used as a generic constraint and you cannot add multiple conformances to Encodable (there cannot be more than one conformance, even with different conditional bounds).

Does anyone have any idea how to implement a change to the stdlib in order to enable the use of RawRepresentable keys?

It's possible, though I'm not sure off the top of my head with which ABI effects, to extend Encodable/Decodable with marker requirements fullfilled by RawRepresentable types:

extension Encodable {
    func __stringRawValue() -> String? { nil }
}

extension Encodable where Self: RawRepresentable, Self.RawValue == String {
    func __stringRawValue() -> String? { return self.rawValue }
}

enum Foo: Int, Encodable {
    case a
}

enum Bar: String, Encodable {
    case b
}

print(Foo.a.__stringRawValue() ?? "nil") // nil
print(Bar.b.__stringRawValue() ?? "nil") // b

It might be possible to take advantage of protocol extensions in this way (or other runtime trickery to make it happen), but...

@Morten_Bek_Ditlevsen

And do anyone have any thoughts about whether this change would be ok. If someone already expects array serialization, then the dictionary behavior will be unexpected.

... the big problem with making this change right now is that it's not backwards-compatible. Even if we enhance Dictionary.init(from:) to be able to decode both forms (legacy unkeyed format, newer preferred keyed format), serialized payloads from newer versions of Swift wouldn't be decodable on older versions. For archived data, this is a serious concern.

There's unfortunately no good "switch" or option to enable somewhere to make it work. Specific encoders and decoders could override behavior for dictionaries to support this (so you could tell, for instance, JSONEncoder to prefer converting RawRepresentable keys to CodingKeys), but this would be on an encoder-by-encoder basis; there's no hook we could add to Dictionary specifically to easily turn this on or off.

---

There's also the practical matter to consider that could affect clients in a surprising way: if you take a type and make it RawRepresentable by an Int or String in a later version of an app/framework, you can suddenly break your data format for yourself or others, with little recourse. Without having a good way to control the behavior, I think it would be too risky and breaking to enable this now.