<div dir="ltr">-1 for all the reasons given so far. Foundation is not a Swift API and the NS prefixes help users understand that. Until Foundation gets an API rewrite that makes it feel native in the Swift ecosystem, it should be made very clear that it is a legacy API and not necessary following Swift best practices. I'm actually quite surprised that the Swift team decided to reimplement Foundation with 100% api compatibility, rather than building a "new and improved" version from scratch.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, May 16, 2016 at 6:37 PM Rob Mayoff via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We (you) shouldn't remove the NS prefixes from most of the classes in<br>
the proposal. I agree with the reasons the other naysayers have given,<br>
but I'll try to restate them in my own words.<br>
<br>
Swift needs a better namespace/import system before these classes<br>
should lose the NS prefix. Right now, you cannot just import one name<br>
from a module. (If you think you can, try typing “import<br>
Foundation.NSDate; NSPort.self” into the REPL.) Therefore we should be<br>
selective about what loses the NS prefix.<br>
<br>
For any type, some fraction of programs need to mention the type by<br>
name in order to justify a prefixless name. What should that threshold<br>
be? Fifty percent? Ten percent? Five percent? String and Int and a<br>
bunch of other types in the standard library can pass a reasonable<br>
threshold. What fraction of programs mention NSTask? NSPort? NSHost?<br>
NSScanner?<br>
<br>
For any name, some fraction of programs would want to use that term<br>
for a program-specific type different than the Foundation type. What<br>
fraction is high enough to justify prefixing the Foundation type name?<br>
E.g. are there enough datebook programs that think "Calendar" should<br>
mean the user's schedule of events, so that Foundation shouldn't claim<br>
the generic term "Calendar"? How about "Timer"? "Task"? "Port"?<br>
"Host"?<br>
<br>
What fraction of these Foundation types would have a substantially<br>
different API if they were designed from scratch in the age of Swift<br>
with the experience of Foundation? Example: NSDate. Looking at each of<br>
JodaTime, NodaTime, and boost::date_time, I see a type representing a<br>
calendar date (e.g. 2016-05-16) with no associated time of day. I've<br>
seen and answered enough questions on stackoverflow to know that iOS<br>
programmers want a type like that. A from-scratch Swift date/time<br>
library would be justified in having such a type, and "Date" would be<br>
a great name for that type (with a prefix or nested in another type,<br>
unless Swift gets a better namespace/import system). NSDate represents<br>
the same thing as CFAbsoluteTime, and should have a name more<br>
representative of that.<br>
<br>
I just don't see the benefit of stripping the NS prefix from most of<br>
the types in Foundation, given the state of those types and the state<br>
of Swift.<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div><div dir="ltr">-- <br></div><div><div dir="ltr"><div><div>Dan Appel<br></div></div></div></div>