<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="">Hi Ryan,<div class=""><br class=""></div><div class="">I don’t have anything concrete yet, but we are taking a very close look at the effect of dropping NS on items in the global namespace. I think it’s pretty clear we will need to do something to make the scope of those constants clearer once the prefix is gone.</div><div class=""><br class=""></div><div class="">- Tony</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 1, 2016, at 11:00 AM, Ryan Breaker via swift-corelibs-dev <<a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@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="">Hello Swift team and contributors!<div class=""><br class=""></div><div class="">I have been wondering about how existing Foundation classes, structs, and such types will be eventually adapted for use in Swift; I understand that, for example, the “NS”-prefix will be removed sometime in Swift 3. What I have been working with most recently has been NSFileManager and its `<font face="Menlo" class="">attributesOfItemAtPath</font>` method which returns a type of <font face="Menlo" class="">[String: AnyObject]</font>. Due to the nature of this, I’ve had to do some digging into the existing corelib-foundation source of NSFileManager to see how each item is assigned and which ones are guaranteed to be set and which ones I should be cautious of (e.g. could be <font face="Menlo" class="">nil</font>).</div><div class=""><br class=""></div><div class="">So that said, are there any plans or thoughts on either changing current types, such as the return type of the aforementioned method, or adding new types to supplement things like this better? For the time being I have written my own <a href="https://github.com/RyanBreaker/SwiftFileAttributes" class="">small Swift module</a> for handling this easier, but I can’t help but feel edgy about it with all the explicit optional unwrapping.</div><br class=""><div class="">
<div style="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; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thanks,<br class="">Ryan Breaker<br class=""><a href="mailto:ryan@breaker.rocks" class="">ryan@breaker.rocks</a></div>
</div>
<br class="">
</div>_______________________________________________<br class="">swift-corelibs-dev mailing list<br class=""><a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev<br class=""></div></blockquote></div><br class=""></div></body></html>