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

Hi Tony, Thanks for the response! As Kevin said: “And if done right, the swiftified types can operate without Foundation at all” This is why I think DispatchData would be superior to NSData, as NSData brings along all the rest of Foundation, whereas the entire Dispatch library looks like a

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

> On May 12, 2016, at 1:32 AM, Patrick Smith via swift-evolution > wrote: > > I second Matthew’s points. I believe dropping NS- is more harmful than > helpful, especially for the future. People have been using Foundation with > the prefix for decades, so I don’t

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

I second Matthew’s points. I believe dropping NS- is more harmful than helpful, especially for the future. People have been using Foundation with the prefix for decades, so I don’t think there’s a longing need that will make using it in Swift unbearable. It has an older Objective-C flavoured

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

> What is your evaluation of the proposal? I very much support hoisting types, updating enumerations, and updating the NSStringEncoding constants. I do not support dropping NS on type level names. Dropping the 2 character prefix is a very small benefit and it comes with very real costs. I

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

Got it. In that case, count me in as +1 for most of the proposal but -1 on AttributedString and its ilk. I agree with you and others that types which are slated to receive the URL/NSURL treatment shouldn't go through an interim renaming dance. On Mon, May 9, 2016 at 20:53 Brent Royal-Gordon

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

> Unless I'm mistaken, NSURL is not among the types being renamed in this > proposal? It is not, because it's already receiving a value-type equivalent. But types like `NSAttributedString`, which the Foundation team eventually intends to provide value-type equivalents for, *are* in the

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

I’m afraid I generally have to agree with this criticism. For types like NSURL which would make sense to become value types in the future, dropping the prefix does seem as if it would put constraints on future growth. I do think the enum hoisting is great, though, and if it were in a separate

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

> • What is your evaluation of the proposal? I support the enum hoisting and case renaming, but not the dropping of the "NS" prefix quite this widely, for several reasons: 1. I agree with the critique that "NSCoder" and its ilk should retain their "NS" prefix because they represent