<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="">On May 6, 2016, at 5:06 PM, Tony Parker via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Hi David,</span><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 6, 2016, at 2:56 PM, David Waite <<a href="mailto:david@alkaline-solutions.com" class="">david@alkaline-solutions.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">-1 On the group as-is. I do not believe all of these classes have the behavior that would be expected if ‘foundation’ were a from-scratch foundational library for Swift (as it exists on non Apple platforms). This will lock Swift into an evolutionary path for these types going forward.</div><div class=""><br class=""></div><div class="">There is enough here that I will just pick one example to focus on - NSCoding/NSCoder, and elements I would suspect from such a from-scratch design</div><div class=""><br class=""></div><div class="">- Coding would incorporate SecureCoding into its design (I did not see NSSecureCoding even on the list of protocols to get the prefix dropped)</div></div></div></blockquote><div class=""><br class=""></div>SecureCoding should be on the list actually.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">- Archiver/Unarchiver would not exist; we would only have keyed versions</div><div class="">- Coder would be a split in half to Coder and Decoder</div><div class="">- Coder and Decoder would be protocols</div><div class="">- The Coder protocol might have a single method, encode(value:Coding, forKey:String)</div><div class="">- The Decoder protocol might single method, <T:Coding> decode(type:T.Type, forKey: String) -> T?</div><div class=""><div class="">- Compiler generation of a default Coding implementation</div><div class=""></div></div><div class=""><br class=""></div><div class="">And possibly more such as:</div><div class="">- Add Coders limited to trees of objects vs graphs, to allow the Coder/Decoder protocols to be used for more intuitive JSON/XML representations</div><div class="">- Custom/specific assignment operator for Decoder to capture desired type without requiring said type to be specified in decode(type:forKey:) calls</div><div class=""><br class=""></div><div class="">-DW</div></div></div></blockquote><div class=""><br class=""></div><div class="">There’s no question that we can improve Coding for Swift. I have actually explored this area quite a bit although I don’t have anything planned for Swift 3 at this time.</div><div class=""><br class=""></div><div class="">The general point is though, that we can do it by extending Foundation in that direction over time. In fact, keyed archiving is the perfect example of how we were able to do just that in the past in Objective-C. NSArchiver already existed and served a particular purpose, so we extended the concept into NSKeyedArchiver using the facilities available to us at the time.</div><div class=""><br class=""></div><div class="">It’s not a goal to rewrite Foundation from scratch in Swift. All Swift apps that are running out there today are in fact using a combination of Swift, Objective-C, C, C++, various flavors of assembly, and more. The goal is to present the existing API of Foundation in a way that fits in with the language today while allowing us to iteratively improve it over time.</div><div class=""><br class=""></div><div class="">- Tony</div></div></div></div></blockquote><br class=""></div><div>The trouble with (NS)Coding is that due to the legacy cruft, you have to consider the possibility that the coder sent to your -initWithCoder: and similar methods could be insecure coders and/or non-keyed coders, and either support each branch (making your method three times as long as it needs to be), or add code to error out if you get one of the legacy coder types.</div><div><br class=""></div><div>A brand new coding mechanism, built from scratch, would be kind of refreshing in that regard.</div><div><br class=""></div><div>Charles</div><div><br class=""></div></body></html>