<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 May 7, 2016, at 6:06 AM, Jonathan Hull <<a href="mailto:jhull@gbis.com" class="">jhull@gbis.com</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="">-1 on this as well. How much does dropping NS really help things anyway? <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="">All it does is force everyone to learn which things still have NS and which don’t. It also makes things much more difficult to search for… searching for NS_ gives the results you want quickly vs searching for anything in Swift foundation (e.g. Array -- which gives you a mixture of other programming languages and Taylor Swift gossip).</div><div class=""><br class=""></div><div class="">My proposal would be to keep NS for everything and then slowing making versions without the prefix, either by rewriting them to be better in Swift or simply aliasing the NS version. Once you have critical mass for useful things (around Swift 5~6), you can separate all the NSStuff out into their own NSFoundation which would be used only for backwards compatibility.</div><div class=""><br class=""></div><div class="">To the inevitable question: Wont having NS and Non-NS versions be confusing (especially if some are just aliases)? My answer is that it is less confusing than this proposal. There is a simple rule: Things without NS are always the new and preferred methods. Things with NS are there for compatibility and will continue to work the way they do in ObjectiveC (even if you have to import “NSFoundation” to get them instead of just “Foundation")</div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>I think that this approach ends up with confusion as well. Maybe we end up with UserDefaults and NSUserDefaults? One is written in Swift and other is not, but what difference would that make to the caller? Swift itself is not written completely in Swift. Instead, let’s have one UserDefaults that has an API appropriate for Swift. You’ve seen some of that already with changes to the names of its methods (<a href="https://github.com/apple/swift/blob/master/apinotes/Foundation.apinotes#L575" class="">https://github.com/apple/swift/blob/master/apinotes/Foundation.apinotes#L575</a> as one example, which takes advantage of overloading to simplify the API).</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="">Side Note: I would also REALLY like to see a swift native improvement on NSAttributedString with native literal support.</div></div></div></blockquote><div><br class=""></div><div>NSAttributedString was part of the value types proposal at the beginning but deferred for a few practical reasons. One reason is that I want additional existential support in the language first. AttributedString has the concept of a “longest effective run”, which is calculated by checking for equality between attributes. Attributed string should allow for AnyEquatableAndCopyable members of its attribute dictionary. A second problem is that the entire Cocoa text system (and hundreds of higher level APIs) are based on top of the NSString Index concept, which is hidden behind the unicodeScalar view of Swift.String. I would like a more unified story of how these two can interoperate before we revamp the base type.</div><div><br class=""></div><div>Both of these are solvable, but they require time to collaborate between teams to decide what the right platform-wide approach is. We’ll do it, but it will not happen immediately.</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=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" 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.
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.</pre></blockquote><div class="">I would be curious to hear about your explorations (either in another thread or offlist)</div><div class=""><br class=""></div><div class="">I have written a couple of experimental versions of an improved Coding system for Swift. The key idea is to use closures to allow coding of arbitrarily complex nested types (e.g an array of tuples of Dictionaries: [(String, [String:Int])] ). It works pretty well, but unfortunately currently taxes the compiler to the point where it randomly crashes during compilation. I am waiting for the new generics stuff to come online before I explore further, since I believe that will dramatically simplify the code.</div></div><div class=""><br class=""></div><div class="">The other idea which I would like to see replicated is that it codes to an intermediate format which can then be transformed to/from binary data, XML, BSON (JSON + some representation for Binary Data) or some other format...</div><div class=""><br class=""></div><div class="">It also interoperates very well with existing NSCoding classes, which is an important feature.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div></div></div></blockquote></div><br class=""><div class="">One thing to think about here is what the role of NSCoding is in the first place. It was designed to support archiving of UI objects to nib files. It has been pressed into service for all kinds of other interesting tasks since; UI state restoration, document formats, and IPC wire protocol, to name a few. It may be worthwhile to decide if these are really all the same use case or not. I’m honestly not sure yet. Some of these are very focused on dynamic behavior (that is, the object graph is not known in advance). For some, custom object types are really important (NSXPC takes full advantage of this, and is basically its reason for existence over the raw libxpc API). For others it is not (a raw document file of one million double values). Some of these have different performance requirements than others (archiving fast is important to IPC but unarchiving fast is important to loading nib files). </div><div class=""><br class=""></div><div class="">- Tony</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>