> On 17 May 2016, at 9:36 AM, Rob Mayoff via swift-evolution > <swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution