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

[Brent Royal-Gordon]

> 	• 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 something very specific to Foundation, not some general concept of a "coder". ("JSONSerialization", on the other hand, *is* something quite generic.)

2. I think the "NS" prefixes may be a valuable indicator of which types are values and which are references. (For this to be the case, we might need to drop some NS prefixes from certain enums.)

3. I am wholly unconvinced by the arguments in the "Keep NS on future value types" section.

Another proposal (I'm behind, so I'm not sure if it's been accepted) suggests that we add a value-typed `URL` to Foundation. Think about what would happen if that proposal were deferred to Swift 4: `NSURL` would be renamed to `URL` in Swift 3, and then Swift 4 would want to use `URL` for something else. At that point, we have several choices, none of them very nice:

* Rename uses of `URL` back to `NSURL`, only one version after making the opposite change. Note that this doesn't only mean migrating code, but also developers' understanding of the frameworks—people will misread code for a while.

* Choose a different name for the new value-typed `URL`, like `URLValue` or `URI` or something. The preferred type then gets a suboptimal name.

* Deprecate the `URL` name, encourage use of `NSURL` instead, and delay the introduction of the new `URL` for a version or two while the deprecation works its magic. Now we've slowed down the evolution of the language.

Any of these seems like a huge own goal next to the alternative of simply leaving all (or most) NS prefixes in place, at least until we feel the main work of adding value types to Foundation is complete.

> 	• Is the problem being addressed significant enough to warrant a change to Swift?

Sure, Foundation needs some cleanup. Just not *this* cleanup.

> 	• Does this proposal fit well with the feel and direction of Swift?

Yes and no. I worry it'll slow the adoption of value types by Foundation, which would not be a good thing.

> 	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

N/A.

> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading, I suppose.

-- 
Brent Royal-Gordon
Architechies