SE-0005 is undergoing public review until the 5th of February. It proposes to automatically convert the way Swift imports Objective-C sourced names.
This proposal describes how we can improve Swift’s “Clang Importer”, which is responsible for mapping C and Objective-C APIs into Swift, to translate the names of Objective-C functions, types, methods, properties, etc. into names that more closely align with the Swift API Design Guidelines being developed as part of Swift 3. Our approach focuses on the differences between the Objective-C Coding Guidelines for Cocoa and the Swift API Design Guidelines, using some simple linguistic analysis to aid the automatic translation from Objective-C names to more “Swifty” names.
Cocoa knowledge capital is hard earned, and a fundamental tool for Apple dev work. I’m not convinced that developers will welcome widespread API adjustments that may incur costs in code review, error detection, maintenance as well as the production of new code. Here is Nate Cook’s take. If you work in Cocoa, I encourage you to take the time to carefully read his write-up.
2 Comments
Are there any arguments in favor of stripping NS other than it being “anachronistic”? It’s a significant API change with non-existent benefits. At least the proposal fails to mention them.
I suspect that many of these proposals are coming from people who spend more of their time reading about proposals than they do making actual products. Out here in the real world, continuity is extremely important. iOS/Mac development is hard enough to keep up with, without having to retrofit EXISTING code and styles to suit someone’s fashions.