<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Karl,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 17, 2017, at 12:20 AM, Karl Wagner 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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 16 Mar 2017, at 21:48, Slava Pestov 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="">Hi Itai,<div class=""><br class=""></div><div class="">I’m wondering what the motivation is for keeping this as part of Foundation and not the standard library. It seems like you’re landing an implementation of this in the Foundation overlay on master, and another copy of all the code will have to go into swift-corelibs-foundation. This seems suboptimal. Or are there future plans to unify the Foundation overlay with corelibs-foundation somehow?</div><div class=""><br class=""></div><div class="">Also the implementation uses some Foundation-isms (NSMutableArray, NSNumber) and it would be nice to stick with idiomatic Swift as much as possible instead.</div><div class=""><br class=""></div><div class="">Finally you should take a look at the integer protocol work (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md</a>) to replace the repetitive code surrounding primitive types, however I don’t know if this has landed in master yet.</div><div class=""><br class=""></div><div class="">Slava</div></div></div></blockquote></div><br class=""><div class="">I agree that the protocols should be part of the standard library rather than Foundation. As far as I can make out, the only part of this proposal that actually requires Foundation is the use of the “Data” type (which itself is a strange and often frustrating omission from the standard library). The actual concrete encoders can live in Foundation.</div><div class=""><br class=""></div><div class="">Generally my opinion is that the proposed feature is nice. Everybody hates NSCoder and having to write those required initialisers on your UIViews and whatnot. At its core, it’s not really very different from any other Swift archiving library which exists today, except that it’s backed with layer upon layer of compiler-generated magic to make it less verbose. The things I don’t like:</div><div class=""><br class=""></div><div class="">1) While making things less verbose is commendable, automatically generating the encoding functions could be an anti-feature. “Codable” is for properties with persistable values only, which is a level of semantics which goes above the type-system. We don’t generate Equatable conformance for structs whose elements are all Equatable; it’s a big leap to go from “this data type <i class="">is persistable</i>” to “the value of this variable <i class="">should be persisted</i>” - for one thing, the value may not have meaning to others (e.g. a file-handle as an Int32) or it may contain sensitive user-data in a String. The encoding function isn’t just boilerplate - you *should* think about it; otherwise who knows what kind of data you’re leaking?</div><div class=""><br class=""></div><div class="">=> One possible solution would be to have “Codable" as a regular protocol, and refine it with “AutoCodable" which contains the magic. Just so there is a little extra step where you think “do I want this to be generated?”.</div></div></div></blockquote><div><br class=""></div><div>The number one complaint we have about NSCoding (and this complaint predates Swift by a long shot) is that too much boilerplate is required for really simple data structures. Resolving this issue is one of our primary goals for this API.</div><div><br class=""></div><div>There are a lot of benefits to keeping one protocol in place instead of making another one for “auto” codable: API which accepts Codable things does not need to have two entry points; there is one concept of Codable instead of two; you can “buy in” to more complex behavior by implementing parts of Codable (e.g., just the keys if you simply want to change the names of the JSON keys).</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">2) More generally, though, I don’t support the idea of the Foundation module introducing extensions to the Swift language that no other developer of any other module has the chance to do, with an aside that some reflection API which doesn’t exist yet might possibly make it less magic in the future. My jaw hit the floor when I saw this was part of the proposal, and that it wasn’t for the standard library. Could you imagine, if somebody proposed their own magic protocols for AlamoFire or Kitura or any other Swift library? It would be a non-starter. It *should* be a non-starter.</div><div class=""><br class=""></div><div class="">=> Do we have a policy about module-specific compiler magic such as this?</div><div class="">=> Can we move any of the magic (e.g. CodableKeys generation) to the standard library?</div><div class=""><br class=""></div><div class="">I develop a lot for platforms, or for scenarios, where Foundation is not supported nor desirable. Considering that people are taught to prefer library code to rolling their own, and that humans are generally quite receptive to shortcuts at the expense of correctness, if this machinery exists at all we can expect it to spread. It would totally kill libraries such as SwiftJSON or whatever else you currently use. The fact that such a fundamental and widespread feature would now live in a monolithic module I can’t access would significantly spoil the language for me.</div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>We’ve been very accepting of patches to port swift-corelibs-foundation to other architectures and platforms, including s390x (<a href="https://github.com/apple/swift-corelibs-foundation/pull/386" class="">https://github.com/apple/swift-corelibs-foundation/pull/386</a>), Android (<a href="https://github.com/apple/swift-corelibs-foundation/pull/622" class="">https://github.com/apple/swift-corelibs-foundation/pull/622</a>), and Cygwin (<a href="https://github.com/apple/swift-corelibs-foundation/pull/381" class="">https://github.com/apple/swift-corelibs-foundation/pull/381</a>). Foundation is extremely portable, so it should be available anywhere that Swift itself is possible to compile.</div><div><br class=""></div><div>Foundation and the Swift standard library also have a more intimate relationship than most other libraries. This is especially relevant on Darwin, where we have special cases for bridging, implementations of various API on String, and more. It’s not a stretch to take advantage of that for this API as well.</div><div><br class=""></div><div>Now, if we had all the language features we needed to avoid any compiler magic then we absolutely would have implemented this with those instead. However, those things aren’t here yet and for some of them (e.g. property behaviors or generalized existentials), there is no plan in place to add them in the near future. Working with JSON is such a common task for so many of our developers that we felt it was important to tackle the problem now with the tools we have at our disposal. </div><div><br class=""></div><div>Of course, we will not be afraid to improve the API in the future as new features are added to the language.</div><div><br class=""></div><div>- Tony</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">- Karl</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>