<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Review of SE-0166 "Swift Archival & Serialization: "<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md</a><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">public protocol CodingKey {<div class=""> associatedtype Key</div><br class=""> var value: Key { get }</div><div class=""><br class=""><div class=""> init?(value: Key)</div></div><div class="">}</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="">What is your evaluation of the proposal?</div><div class="">+1000</div><div class=""><br class=""></div><div class="">Is the problem being addressed significant enough to warrant a change to Swift?</div><div class="">Yes</div><div class=""><br class=""></div><div class="">Does this proposal fit well with the feel and direction of Swift?</div><div class="">Yes</div><div class=""><br class=""></div><div class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</div><div class="">N/A</div><div class=""><br class=""></div><div class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</div><div class="">Read the whole proposal, did my best to understand it but it's a lot to digest.</div></div><div class=""><br class=""></div></body></html>