> 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 believe unprefixed top level names should not be taken without a manual review of the API design. 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. 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. I hope that we will move forward with most of this proposal while keeping the NS prefix for top-level names. > Is the problem being addressed significant enough to warrant a change to > Swift? 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. > Does this proposal fit well with the feel and direction of Swift? Mostly yes. However, taking top-level unprefixed names without a process of Swiftification does not. > If you have used other languages or libraries with a similar feature, how do > you feel that this proposal compares to those? I think this question is N/A for this proposal. 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. 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. > How much effort did you put into your review? A glance, a quick reading, or > an in-depth study? I participated in the discussion, read the proposal, and carefully considered the consequences of each piece. > More information about the Swift evolution process is available at > > https://github.com/apple/swift-evolution/blob/master/process.md > <https://github.com/apple/swift-evolution/blob/master/process.md> > Thank you, > > -Doug Gregor > > Review Manager > > _______________________________________________ > swift-evolution-announce mailing list > swift-evolution-annou...@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution-announce
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
