[swift-evolution] Dropping NS Prefix in Foundation

[Haravikk]

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 <swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution