<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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 approach, relying heavily on classes, run loops, key value observing (e.g. NSOperation), exceptions, and notifications. I think its philosophy will stand out more than its NS- prefix. Even if many classes become value types, it feels more like a port.</div><div class=""><br class=""></div><div class="">I think for something to be so central as the recommended ‘foundational’ library for Swift, it carries too much baggage, which is unfortunate in the light of Swift’s radical eagerness to reject unnecessary legacy.</div><div class=""><br class=""></div><div class="">Many Foundation classes expect NSObject subclasses for delegates and for key value coding & observing. Key value observing requires on-the-fly subclassing at run time, something which goes strongly against Swift’s philosophy AFAIK.</div><div class=""><br class=""></div><div class="">Foundation is in some cases a wrapper around underlying technologies such as GCD, because years ago an Objective-C wrapper was seen as a more friendly, more safe, and a more familiar object-oriented approach. With Swift we have the power to make those technologies themselves more friendly, safe, and familiar with modernisations such as the current proposal for libdispatch. Extensions allow us to add properties and methods directly to the native types.</div><div class=""><br class=""></div><div class="">NSURL has methods such as .getResourceValue(_:forKey:) that involve mutable state.</div><div class=""><br class=""></div><div class="">I think removing the prefixes will take valuable real estate for types such as ‘URL’ and ‘Data’, which instead can have new replacements made, focused on the use-cases of only Swift. I think DispatchData could be a fine choice for ‘Data’, and has the strong benefit that it bridges to NSData on Darwin.</div><div class=""><br class=""></div><div class="">I fully support the idea of improving Foundation, and of there being a Linux-compatible version. I don’t support it being as first class as the standard library or libdispatch, and don’t support removing the NS prefixes.</div><div class=""><br class=""></div><div class="">Patrick</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 11 May 2016, at 1:36 AM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><ul style="box-sizing: border-box; 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);" class=""><li style="box-sizing: border-box;" class="">What is your evaluation of the proposal?</li></ul></div></div></blockquote><div class="">I very much support hoisting types, updating enumerations, and updating the NSStringEncoding constants. </div><div class=""><br class=""></div><div class="">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 believe unprefixed top level names should not be taken without a manual review of the API design. </div><div class=""><br class=""></div><div class="">Types which will be value types in the future are obvious candidates for redesign but are not the only types whose API would benefit by human consideration and Swiftification. Keeping the NS prefix until this happens recognizes that the Swiftification of Foundation is a work in progress. It will give us more options in the future that don’t involve breaking changes. </div><div class=""><br class=""></div><div class="">It will also serve as a signal to developers about what kinds of APIs should be considered idiomatic in Swift. If we want developers to learn how to distinguish idiomatic Swift, our API guidelines, etc from Objective-C mappings we need to provide some cues. I believe name prefixes are a good way to do this.</div><div class=""><br class=""></div><div class="">I hope that we will move forward with most of this proposal while keeping the NS prefix for top-level names.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><ul style="box-sizing: border-box; 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);" class=""><li style="box-sizing: border-box;" class="">Is the problem being addressed significant enough to warrant a change to Swift?</li></ul></div></div></blockquote><div class="">Yes, but we need to do this carefully, deliberately and in a way that we won’t regret in the future. I believe several parts of the proposal are warranted, but the namesake “drop NS prefix” portion should deferred until each type receives manual consideration and possibly redesign.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><ul style="box-sizing: border-box; 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);" class=""><li style="box-sizing: border-box;" class="">Does this proposal fit well with the feel and direction of Swift?</li></ul></div></div></blockquote><div class="">Mostly yes. However, taking top-level unprefixed names without a process of Swiftification does not.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><ul style="box-sizing: border-box; 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);" class=""><li style="box-sizing: border-box;" class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</li></ul></div></div></blockquote><div class="">I think this question is N/A for this proposal.</div><div class=""><br class=""></div><div class="">I hesitate in saying this, but I think the best comparison to consider is the origin of Foundation and Cocoa themselves. They are fantastic Objective-C APIs. If they had originated by wrapping pre-existing APIs written in a different language with different idioms and then incrementally enhanced I wonder if they may have been less fantastic. </div><div class=""><br class=""></div><div class="">I believe reserving unprefixed top-level names for manually designed, idiomatic types is the path for Swift that avoids this risk altogether and gives us the best chance possible at an incredible, idiomatic set of libraries.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><ul style="box-sizing: border-box; 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);" class=""><li style="box-sizing: border-box;" class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</li></ul></div></div></blockquote><div class="">I participated in the discussion, read the proposal, and carefully considered the consequences of each piece.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><p style="box-sizing: border-box; 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);" class="">More information about the Swift evolution process is available at</p><blockquote style="box-sizing: border-box; margin: 0px 0px 16px; padding: 0px 15px; color: rgb(119, 119, 119); border-left-width: 4px; border-left-style: solid; border-left-color: rgb(221, 221, 221); 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);" class=""><div style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px;" class=""><a href="https://github.com/apple/swift-evolution/blob/master/process.md" style="box-sizing: border-box; background-color: transparent; -webkit-text-decoration-skip: objects; color: rgb(64, 120, 192); text-decoration: none;" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a></div></blockquote><p style="box-sizing: border-box; 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);" class="">Thank you,</p><p style="box-sizing: border-box; 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);" class="">-Doug Gregor</p><p style="box-sizing: border-box; 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);" class="">Review Manager</p></div>_______________________________________________<br class="">swift-evolution-announce mailing list<br class=""><a href="mailto:swift-evolution-announce@swift.org" class="">swift-evolution-announce@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution-announce" class="">https://lists.swift.org/mailman/listinfo/swift-evolution-announce</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>