If I am coming to Swift as a new user (possibly as a first language, even) without any prior Objective-C experience and very little knowledge of the long history of Foundation, the NS prefix, etc, this is going to feel worse than a little out of place - it will feel downright wrong, broken, and confusing to see these weird NS prefixes on some seemingly “standard” classes and not on others.
I’m +1 for removing the NS and evolving forward from there - let’s not create a confusing tangle of old and new that is navigable only by those with knowledge of the esoteric. l8r Sean > On May 9, 2016, at 5:33 AM, Haravikk via swift-evolution > <[email protected]> wrote: > > I have mixed feelings about this; while I agree that prefixing names isn’t a > good fit for Swift, at the same time that’s kind of the appeal of it. > Assuming that Foundation will eventually be replaced by a more Swift-like > alternative, or will be incrementally reworked, I think it makes sense for it > to feel a little weird to use as it is right now. > > The NS prefix makes it clear that this is something different, something not > originally designed with Swift in mind, and in a way that’s a good thing. I > know in my own case it makes me instinctively shy away from it, and actually > encourages me to wrap NS constructs in something more Swift-like for > convenience. > >> On 6 May 2016, at 21:52, Tony Parker via swift-evolution >> <[email protected]> wrote: >> >> Hi everyone, >> >> Thanks to all of you for your feedback on SE-0069 (Foundation Value Types). >> I’m back again with more information on another part of our plan to >> integrate Foundation API into Swift: dropping the NS prefix. >> >> When we originally proposed this as part of the API guidelines document >> (SE-0023, >> https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md), >> we took a very broad approach to which classes would drop their prefix. >> This time, we’ve narrowed the scope considerably, plus taken advantage of >> the ability to nest types inside classes to further reduce the possibility >> of introducing conflicting names. >> >> I’ve written up a draft of the proposal, which includes an extensive section >> on motivation plus a list of changes. Please take a look and let me know >> what you think. We’ll start a formal review period soon. >> >> https://github.com/parkera/swift-evolution/blob/parkera/drop_ns/proposals/NNNN-drop-foundation-ns.md >> >> Thanks again for your help, >> - Tony >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
