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

[Anders Ha]

> On 17 May 2016, at 9:36 AM, Rob Mayoff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.

You can. Try `import class Foundation.NSDate`. :)
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.
> 
> 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160517/befcb819/attachment.html>