Better Translation of Objective-C APIs Into Swift
Proposal SE-0005 has been accepted:
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.
The new names will not be as Googleable, and this may make switching back and forth between Swift and Objective-C more difficult. But I think it’s a good move to leverage the type system to make the APIs more concise, but not overly so.
Update (2016-02-03): Nate Cook:
This is a concurring opinion with Drew’s review, agreeing that we should reconsider removing the “NS” prefix but providing my own reasons. The proposal as a whole is exciting and far-reaching, but this particular change is misguided.
1) The change will elide the different semantic expectations for Foundation and Swift standard library types.
[…]
2) The change may stifle the development of more Swift-oriented APIs.
[…]
3) The change will make it harder to find information about the revised APIs.
No, the elimination of 2 characters is not significant enough of a problem to break all Swift programs, let alone to introduce literally thousands of new opportunities for shadowing.
2 Comments RSS · Twitter
[…] is a struct or a class, which adds another. It’s even more complicated in the context of the proposal to remove the “NS” prefix from Foundation class […]
