[swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Rob Mayoff]

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.