<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=""><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 17 May 2016, at 9:36 AM, Rob Mayoff 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 class="">We (you) shouldn't remove the NS prefixes from most of the classes in<br class="">the proposal. I agree with the reasons the other naysayers have given,<br class="">but I'll try to restate them in my own words.<br class=""><br class="">Swift needs a better namespace/import system before these classes<br class="">should lose the NS prefix. Right now, you cannot just import one name<br class="">from a module. (If you think you can, try typing “import<br class="">Foundation.NSDate; NSPort.self” into the REPL.) Therefore we should be<br class="">selective about what loses the NS prefix.<br class=""></div></div></blockquote><br class=""><div>You can. Try `import <i class=""><b class="">class</b></i> Foundation.NSDate`. :)</div><div>That’s said there are cases which it won’t work. Say if you try to import CGFloat from UIKit/CoreGraphics, it seems a few conformances are lost, e.g. FloatLiteralConvertible.</div><blockquote type="cite" class=""><div class=""><div class=""><br class="">For any type, some fraction of programs need to mention the type by<br class="">name in order to justify a prefixless name. What should that threshold<br class="">be? Fifty percent? Ten percent? Five percent? String and Int and a<br class="">bunch of other types in the standard library can pass a reasonable<br class="">threshold. What fraction of programs mention NSTask? NSPort? NSHost?<br class="">NSScanner?<br class=""><br class="">For any name, some fraction of programs would want to use that term<br class="">for a program-specific type different than the Foundation type. What<br class="">fraction is high enough to justify prefixing the Foundation type name?<br class="">E.g. are there enough datebook programs that think "Calendar" should<br class="">mean the user's schedule of events, so that Foundation shouldn't claim<br class="">the generic term "Calendar"? How about "Timer"? "Task"? "Port"?<br class="">"Host"?<br class=""><br class="">What fraction of these Foundation types would have a substantially<br class="">different API if they were designed from scratch in the age of Swift<br class="">with the experience of Foundation? Example: NSDate. Looking at each of<br class="">JodaTime, NodaTime, and boost::date_time, I see a type representing a<br class="">calendar date (e.g. 2016-05-16) with no associated time of day. I've<br class="">seen and answered enough questions on stackoverflow to know that iOS<br class="">programmers want a type like that. A from-scratch Swift date/time<br class="">library would be justified in having such a type, and "Date" would be<br class="">a great name for that type (with a prefix or nested in another type,<br class="">unless Swift gets a better namespace/import system). NSDate represents<br class="">the same thing as CFAbsoluteTime, and should have a name more<br class="">representative of that.<br class=""><br class="">I just don't see the benefit of stripping the NS prefix from most of<br class="">the types in Foundation, given the state of those types and the state<br class="">of Swift.<br class="">_______________________________________________<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></div></blockquote></div><br class=""></body></html>