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