<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="">-1 on this as well. How much does dropping NS really help things anyway? <div class=""><br class=""></div><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 class="">Side Note: I would also REALLY like to see a swift native improvement on NSAttributedString with native literal support.</div><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></body></html>