SE-0320: Coding of non String / Int keyed Dictionary into a KeyedContainer

[Morten_Bek_Ditlevsen]

Thank you so much for your comments, @itaiferber , @Tony_Parker and @benrimmington !

I think that it would probably be best not to touch _DictionaryCodingKey - and also to not expose any public CodingKey implementation.

You mention a non-roundtripping CodingKey implementation, @benrimmington :

@benrimmington

In the current proposal, without an associated type, a key with unrelated string and integer values may not round-trip:

First of all, I thought I understood enum CodingKey conformance. I thought it was all done through the RawRepresentable conformance, but as I can gather from your comment and from the example there's code synthesis involved. I did not know that. :-)

Secondly: Is this something that should be fixed? Or might this behavior be expected in case you craft a CodingKey so cunningly? Isn't it you own 'responsibility' that a CodingKey round-trips? I mean, it's easy to create CodingKeys that do not:

struct Test: CodingKey {
    var stringValue: String = "hello"
    init?(stringValue: String) {
        return nil
    }
    var intValue: Int? { return 23 }
    init?(intValue: Int) {
        return nil
    }
}

[Morten_Bek_Ditlevsen]

Hi @benrimmington ,
Would you happen to have any feedback for my latest question?

[benrimmington]

@Morten_Bek_Ditlevsen

Would you happen to have any feedback for my latest question?

I've already posted too much in this review, but it seems that a similar example was previously discussed in the pitch thread. (The feedback was that most types won't have this issue, so an associated type isn't worthwhile.)

[Morten_Bek_Ditlevsen]

Thanks you so much, @benrimmington .

[tomerd]

This review for SE-0320 has concluded and the proposal was returned for revision.

Thank you to everyone for the feedback and contributions to this proposal.