We (you) shouldn't remove the NS prefixes from most of the classes in the proposal. I agree with the reasons the other naysayers have given, but I'll try to restate them in my own words.
Swift needs a better namespace/import system before these classes should lose the NS prefix. Right now, you cannot just import one name from a module. (If you think you can, try typing “import Foundation.NSDate; NSPort.self” into the REPL.) Therefore we should be selective about what loses the NS prefix. For any type, some fraction of programs need to mention the type by name in order to justify a prefixless name. What should that threshold be? Fifty percent? Ten percent? Five percent? String and Int and a bunch of other types in the standard library can pass a reasonable threshold. What fraction of programs mention NSTask? NSPort? NSHost? NSScanner? For any name, some fraction of programs would want to use that term for a program-specific type different than the Foundation type. What fraction is high enough to justify prefixing the Foundation type name? E.g. are there enough datebook programs that think "Calendar" should mean the user's schedule of events, so that Foundation shouldn't claim the generic term "Calendar"? How about "Timer"? "Task"? "Port"? "Host"? What fraction of these Foundation types would have a substantially different API if they were designed from scratch in the age of Swift with the experience of Foundation? Example: NSDate. Looking at each of JodaTime, NodaTime, and boost::date_time, I see a type representing a calendar date (e.g. 2016-05-16) with no associated time of day. I've seen and answered enough questions on stackoverflow to know that iOS programmers want a type like that. A from-scratch Swift date/time library would be justified in having such a type, and "Date" would be a great name for that type (with a prefix or nested in another type, unless Swift gets a better namespace/import system). NSDate represents the same thing as CFAbsoluteTime, and should have a name more representative of that. I just don't see the benefit of stripping the NS prefix from most of the types in Foundation, given the state of those types and the state of Swift. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
