Wednesday, January 13, 2016

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.

Drew Crawford:

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 […]

[…] Previously: Better Translation of Objective-C APIs Into Swift. […]

Leave a Comment