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

[Kevin Ballard]

On Mon, May 9, 2016, at 03:20 PM, Douglas Gregor via swift-evolution wrote:
>  * What is your evaluation of the proposal?
 
+1 to enum renaming / hoisting, including turning NSStringEncoding into
an enum, but -1 on dropping the NS prefix. I agree with a lot of what
the other -1 people have said, but the 2 biggest reasons for me are:
 
1. The NS prefix is a signal that the type is probably an Objective-C
   class, and with the enum renaming/hoisting this signal will become
   even stronger. The fact that it's an Objective-C class means that
   it's not Swift-like, it's a reference type, it doesn't participate in
   copy-on-write mutation, etc.
 
2. Dropping the NS prefix means that a *lot* of pretty generic names are
   now owned by Foundation, which makes it difficult to implement the
   same concept in the Swift standard library. A lot of these names
   aren't likely to end up in the Swift stdlib, but I'd rather be
   cautious about this and not take any of these names.
 
By keeping the NS prefixes, we can then "swiftify" these APIs on an
ongoing basis and drop the prefix once a type has been "swiftified"
(which includes turning things into value types when applicable, not
merely renaming methods). And if done right, the swiftified types can
operate without Foundation at all, the same way
String/Array/Dictionary/Set are independent implementations that bridge
to/from Obj-C.
 
As a side note, regardless of everything else, we really should not
rename NSJSONSerialization to JSONSerialization. This class is a
specific implementation of a JSON encoder/decoder that operates on
Foundation types. The name JSONSerialization should be reserved for the
potential use of a Swift-native JSON encoder/decoder.

>  * Is the problem being addressed significant enough to warrant a
>    change to Swift?
 
I don't think so. I'm not sure what the benefit of dropping the "NS"
prefix is supposed to be at all, besides saving 2 keystrokes. The
proposal says this is to "establish these libraries as fundamental and
native Swift libraries" by "making their naming style match the
convention established by the standard library", but I don't think this
is actually the right way to do this. Renaming these classes doesn't
make the API feel like native Swift (biggest example is value vs
reference types). What would make them feel like native Swift is writing
a native Swift type with a native Swift API and native Swift conventions
that bridges to/from the obj-c class (e.g. how Swift 3 is gaining the
URL value type).

>  * How much effort did you put into your review? A glance, a quick
>    reading, or an in-depth study?
 
A quick reading of the proposal, as well as reading previous discussions
about this topic.
 
-Kevin Ballard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160512/27d063df/attachment.html>