<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=""><br class=""><div><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 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 class="">- Karl</div></body></html>