Added protocol CodingKeyRepresentable

[mortenbekditlevsen]

This PR contains an implementation for the accepted Swift Evolution proposal: SE-0320.

The current Codable system has an issue that only String and Int can be used as keys in keyed containers.
This has been discussed on various topics on the Swift Evolution forums <TODO - find references>. I believe that it has been mentioned by Itai Ferber that it was an early oversight that types that are RawRepresentable as String or Int could not be used as keys <TODO - find reference>.

It is unfortunately too late to fix this now. For one it is a behavior breaking change - and furthermore the change is tied to the Swift stdlib, so the behavior would basically differ between different consumers of the code (for instance different behaviors on different iOS versions).

I had another take at this issue: #26257
The idea there was to be able to express an opt-in to the new (fixed?) behavior directly in the JSONEncoder and JSONDecoder types by venting a new encoding/decoding 'strategy' configuration.

I have since changed my personal opinion about this and I believe that the problem should not just be fixed for specific Encoder/Decoder pairs, but rather for all.

This PR is an attempt to fix the situation by adding a new protocol: CodingKeyRepresentable. By adding conformance to the type of a key, you will be opting in to having dictionaries with keys of this type to encode as dictionaries instead of arrays of key/value pairs.

The opt-in can only happen for a version of swift where the protocol is available, so the user will be in full control of the situation. For instance I am currently using my own workaround, but once I only support iOS versions running a specific future Swift X version with this feature, I could skip my own workaround and rely on this behavior instead.

This draft PR is a placeholder so that I can start a Swift Evolution discussion. Perhaps even a pitch.

[benrimmington]

The new and old behaviors will need to be tested somehow.

[benrimmington]

You can try the following, from within the swift directory:

utils/run-test \
  --build-dir=../build/Ninja-RelWithDebInfoAssert \
  --build=true \
  --subset=all \
  --target=macosx-x86_64 \
  --verbose \
  test/stdlib/CodableTests.swift

(The exact --build-dir and --target arguments may vary, depending on your machine and build options.)

[benrimmington]

Is this ready for merging, or is there anything else I can do? 😊

@mortenbekditlevsen You could update the comment at the top of this page, with a link to the SE-0320 proposal.

I don't know who the "code owner" is, but I've requested reviews from:

• @amartini51 (documentation)
• @lorentey (standard librarian)
• @tbkka (performance re: Reduce generics in Codable #31278)

[amartini51]

Thanks for asking me to review, and for adding & updating the doc comments! Suggested some minor changes and left a question.

[amartini51]

Thanks for making the doc changes — I'll mark this as "approve" even though I asked you to add a comma. With that last change, these look good to me.

[benrimmington]

Some lines are over the 80-character limit.

(I didn't attempt to reformat the CodableTests.swift file.)

[mortenbekditlevsen]

Thank you @benrimmington ,
I also didn't attempt reformatting CodableTests.swift - it appears that the 80 character line limit is not respected elsewhere in that file.

[mortenbekditlevsen]

Apologies for bumping this: is there anything else I can do for now? I am not familiar with the usual process after a proposal has been accepted. @lorentey @tbkka

Out of curiosity: I have not seen any plans for the next Swift version, but I assume that it will be 5.6. Are you familiar with any timeline for the next release?

[benrimmington]

@swift-ci Please smoke test

[benrimmington]

Out of curiosity: I have not seen any plans for the next Swift version, but I assume that it will be 5.6. Are you familiar with any timeline for the next release?

The next version is Swift 5.6, but I haven't seen an announcement yet. Based on the table of previous announcements, a release/5.6 branch might be created in December (and the release might be in March or April).

[mortenbekditlevsen]

Hi @drexin ,
Excuse me for bumping, but I'm so excited for my SE proposal to land in Swift.
Anything I can do to push this forward?
Sincerely,
/morten

[drexin]

Looks good to me!

[drexin]

@swift-ci test windows

[drexin]

@swift-ci smoke test

[benrimmington]

The mangledName is now required: #39846

[mortenbekditlevsen]

Thank you @benrimmington

[drexin]

@swift-ci smoke test

[mortenbekditlevsen]

Yaaaaaay! Thank you so much to everyone who helped! 😊🥰🎉