<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="">Hi Oliver,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 23, 2017, at 7:55 AM, Oliver Jones via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Like everyone I’m excited by this new proposal. But…</div><div class=""><br class=""></div><div class="">> protocol Codable: Adopted by types to opt into archival. Conformance may be automatically derived in cases where all properties are also Codable.<br class=""><div class=""><br class=""></div><div class="">… can I make one suggestion. Please do not repeat the mistakes of NSCoding in combining the encoding and decoding into a single protocol. Just as there are Encoder and Decoder classes their should be Encodable and Decodable protocols (maybe have an aggregate Codable protocol for convenience but do not force it).</div></div><div class=""><br class=""></div><div class="">My reasoning:</div><div class=""><br class=""></div><div class="">Sometimes you only want to decode <b class="">or</b> encode and object and not vice versa. This is often the case with Web APIs and JSON serialisation. </div><div class=""><br class=""></div><div class="">Eg:</div><div class=""><br class=""></div><div class="">Often an app only consumes (decodes) JSON encoded objects and never writes them out (a read only app for example). So the encode(to:) methods are completely redundant and someone adopting Codable should not be forced to write them. </div><div class=""><br class=""></div><div class="">If only I had a dollar for all the times I’ve seen this sort of code in projects:</div><div class=""><br class=""></div><div class="">class MyClass : NSCoding {</div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">init?(coder: NSCoder) {</div><div class=""> // ... some decoding code</div><div class="">}</div><div class=""><br class=""></div><div class="">func encode(with aCoder: NSCoder) {</div><div class=""> preconditionFailure(“Not implemented”)</div><div class="">}</div></blockquote><div class="">}</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Another example: </div><div class=""><br class=""></div><div class="">Web APIs often take data in a different structure as input (i.e. “Request” objects) than they output. These request objects are only ever encoded and never decoded by an application so implementing init(from:) is completely redundant.</div><div class=""><br class=""></div><div class="">Personally I think the approach taken by libraries like Wrap (<a href="https://github.com/johnsundell/wrap" class="">https://github.com/johnsundell/wrap</a>) and Unbox (<a href="https://github.com/JohnSundell/Unbox" class="">https://github.com/JohnSundell/Unbox</a>) is a much better design. Encoding and decoding should not be the same protocol.</div><div class=""><br class=""></div><div class="">Yes I understand that Codable could provide no-op (or preconditionFailure) protocol extension based default implementations of init(from:) and encode(to:) (or try to magic up implementations based on the Codable nature of public properties as suggested in the proposal) but to me that seems like a hack that is papering over bad design. I think this joint Codable design probably fails the Liskov substitution principle too.</div><div class=""><br class=""></div><div class="">So I again implore you to consider splitting Codable into two protocols, one for encoding and another for decoding.</div><div class=""><br class=""></div><div class="">Sorry if I’m repeating what other people have already said. I’ve not read every response to this proposal on the list.</div><div class=""><br class=""></div><div class="">Regards</div></div></div></div></blockquote><div><br class=""></div></div>Thanks for your feedback. We are indeed considering splitting this up into 3 protocols instead of 1 (“Encodable", “Decodable", "Codable : Encodable, Decodable”).</div><div class=""><br class=""></div><div class="">The main counterpoint is the additional complexity inherent in this approach. We are considering if the tradeoff is worth it.</div><div class=""><br class=""></div><div class="">- Tony</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>