<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 Slava,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 16, 2017, at 1:50 PM, 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=""><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></div></blockquote><div><br class=""></div>I would like some unification in the future, but they are currently two separate implementations for a bunch of reasons (lack of bridging on Linux being a huge one, along with the inability of the standard library and runtime to distinguish between presence of Objective-C and the presence of Foundation).</div><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="">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></div></blockquote><div><br class=""></div>The implementation you’re looking at is for JSONArchiver, which is based on NSJSONSerialization, which is part of Foundation and not the standard library. That’s a primary reason to use Foundation. NSJSONSerialization also deals with types like ‘Date’ which are in Foundation. Finally, the primitive Coding API uses Data, which is a Foundation type.</div><div><br class=""></div><div>So in summary, I’m fine with this API being part of Foundation. Foundation is available the same places the standard library is, so it is more than acceptable to use Foundation API and types here.</div><div><br class=""></div><div>- Tony</div><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="">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></div></blockquote><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="">Slava</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>