<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md</a>]<div class=""><br class=""></div><div class="">There's some pretty cool stuff in here. Nice work. I do have a few questions about this design, though:</div><div class=""><br class=""></div><div class="">- Why are the encoders and decoders open classes? (In particular, the fixed set of "strategies" seems like it'll be a problem if we plan to keep adding cases.) For that matter, why make them classes at all?</div><div class=""><br class=""></div><div class="">- I don't understand 'DateEncodingStrategy.deferredToDate'. It seems like this will always match one of the other cases in practice, and it isn't safe for any stable encoding.</div><div class=""><br class=""></div><div class="">- I assume you've thought about this, but there's no way for existing Cocoa types to conform to Decodable, since it introduces a new required initializer.* The design here doesn't rely on that at all, but I feel like it's worth calling out explicitly.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">* Why does Decodable introduce a required initializer? Because when a class conforms to a protocol, it's declaring that it <i class="">and all its subclasses</i> conform to the protocol. But since initializers are not automatically inherited in Swift, there's no way to add new initializers to all existing subclasses.</div><div class=""><br class=""></div><div class="">Jordan</div></body></html>