[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md <https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md>]
There's some pretty cool stuff in here. Nice work. I do have a few questions about this design, though: - 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? - 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. - 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. * Why does Decodable introduce a required initializer? Because when a class conforms to a protocol, it's declaring that it and all its subclasses 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. Jordan
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
