[swift-evolution] [Review] SE-0166: Swift Archival & Serialization

Robert Bennett rltbennett at icloud.com
Fri Apr 7 22:15:34 CDT 2017


Review of SE-0166 "Swift Archival & Serialization: "https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md <https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md>

This is an amazing proposal. I have one question about the CodingKey protocol, though. It feels strange to provide two ways to access keys, String for convenience/clarity and Int for performance, and to have those both floating around when only at most one will be used by an Encoder. It's very likely I'm missing something here (certainly I haven't thought about this as much as the authors of the proposal) but would it make more sense to write CodingKey like this?

public protocol CodingKey {
    associatedtype Key

    var value: Key { get }

    init?(value: Key)
}

For any enum conforming to CodingKey, the compiler can still generate the implementations of those methods using String as Key, although I don't see why it would when using Int is more performant. It might also be necessary to have a protocol CodingKeyKeyProtocol (yech) to constrain the Key type — associatedtype Key: CodingKeyKeyProtocol — to something that can be used as an Encoder/Decoder key. It's possible that Hashable is already sufficient for this protocol. This would allow more flexible custom types conforming to CodingKey, although I'm not sure if that flexibility is needed. I'm also not sure anything aside from Int is needed, in which case the associatedtype could be removed and Key replaced with Int.



What is your evaluation of the proposal?
+1000

Is the problem being addressed significant enough to warrant a change to Swift?
Yes

Does this proposal fit well with the feel and direction of Swift?
Yes

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
N/A

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Read the whole proposal, did my best to understand it but it's a lot to digest.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170407/a66bb9b6/attachment.html>


More information about the swift-evolution mailing list