[WIP] Using RawRepresentable String keys for Dictionaries with JSONEncoder and JSONDecoder

[mortenbekditlevsen]

Currently Dictionary will encode and decode kay/value pairs to unkeyed containers in case the key is not String or Int.

This PR is a WIP implementation of a workaround specifically for JSONEncoder and JSONDecoder that is hidden behind an option in order to make it backwards compatible with the current implementation.

The issue is briefly discussed here: https://forums.swift.org/t/using-rawrepresentable-string-and-int-keys-for-codable-dictionaries/26899

The PR partly deals with the issue:
https://bugs.swift.org/browse/SR-7788
but only with regard to String RawRepresentable keys - and only for the JSONEncoder and JSONDecoder.

[mortenbekditlevsen]

Things that I would very much like input on:

The name of the option is currently not very good. I have a real hard time coming up with a good and descriptive name.

Is the concept of using 'encode' and 'decode' for the keys ok? I think that it's a natural thing to do, but currently I have hacked around the 'canEncodeNewValue' by pushing a dummy key on the codingPath before encoding.

How do you properly add availability flags for the next swift version?

[mortenbekditlevsen]

@itaiferber have you had a chance to look at my take on this?

[itaiferber]

@mortenbekditlevsen Sorry, I didn't see this when you originally put this up. I'll try to getting to review it as soon as I can. :)

[mortenbekditlevsen]

@itaiferber Do you think there’s perhaps a better way to achieve this?

[mortenbekditlevsen]

@itaiferber Sorry for pestering you. Have you by any chance had time to consider this?

[itaiferber]

@mortenbekditlevsen Not pestering! Though unfortunately, I can't be of much help anymore as I no longer work at Apple. @parkera might have a suggestion for who should review this instead.

[mortenbekditlevsen]

Hi @itaiferber ,
I am selfishly sorry to hear that, because I am a huge fan of your work at Apple and everything regarding Codable in Swift in particular.
I wish you the best of luck in your future endeavors!

[itaiferber]

Thanks, @mortenbekditlevsen! I appreciate that, and wish the same to you! 😄

[parkera]

I'd like to keep considering this concept (perhaps more in the thread since there are other ideas there). I don't have a concrete answer yet on when we should do it though.

[mortenbekditlevsen]

Hi @parkera ,
I tried reviving the topic on the Swift Forums with this post: https://forums.swift.org/t/using-rawrepresentable-string-and-int-keys-for-codable-dictionaries/26899/11?u=morten_bek_ditlevsen

Unfortunately I have not received any feedback for my latest post yet.
Can you think of anything I might do to get the relevant people (perhaps within Apple) to consider the issue?

[parkera]

I think the best thing I can do for this is file a radar for us to track it internally. That doesn't provide any guarantee of when we'll have the bandwidth to work on it, but it will ensure that we don't lose it. I have gone ahead and done that (rdar://problem/57410395)

[shahmishal]

Please update the base branch to main by Oct 5th otherwise the pull request will be closed automatically.

• How to change the base branch: (Link)
• More detail about the branch update: (Link)

[mortenbekditlevsen]

I will close this issue, as my personal opinion for how to solve this has changed.
I think a better way to go is to introduce a new protocol. Something like StringKeyCodable - which is basically RawRepresentable for Strings. Adding conformance for this new type would be a way to opt into having dictionaries encode as keyed containers and vice versa for decoding.
I know that adding new protocols are controversial, but either this needs to be fixed in each Encoder/Decoder pair (as this PR tried to do) using configuration options - or it needs to be solved in the encoding and decoding of the Dictionary itself - and to do that without breaking anything would require something like this new protocol.
I will try to create a PR with my other idea, and pitch it on the forums when I have time.

[Jason-Abbott]

Some Internet searches are still directing here so note there is now Swift Language support for this in the form of CodingKeyRepresentable (which mentions this PR but it’s easy to miss the note, above). See

• Developer Documentation
• Original Swift Proposal
• Sample code