<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Mon, May 9, 2016, at 03:20 PM, Douglas Gregor via swift-evolution wrote:<br></div>
<blockquote type="cite"><ul style="padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(51, 51, 51);font-family:'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol';font-size:16px;background-color:rgb(255, 255, 255);"><li style="">What is your evaluation of the proposal?<br></li></ul></blockquote><div> </div>
<div>+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:<br></div>
<div> </div>
<div>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.<br></div>
<div> </div>
<div>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.<br></div>
<div> </div>
<div>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.<br></div>
<div> </div>
<div>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.<br></div>
<div> </div>
<blockquote type="cite"><ul style="padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(51, 51, 51);font-family:'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol';font-size:16px;background-color:rgb(255, 255, 255);"><li style="">Is the problem being addressed significant enough to warrant a change to Swift?<br></li></ul></blockquote><div> </div>
<div>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).<br></div>
<div> </div>
<blockquote type="cite"><ul style="padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(51, 51, 51);font-family:'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol';font-size:16px;background-color:rgb(255, 255, 255);"><li style="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br></li></ul></blockquote><div> </div>
<div>A quick reading of the proposal, as well as reading previous discussions about this topic.<br></div>
<div> </div>
<div>-Kevin Ballard</div>
</body>
</html>