[swift-evolution-announce] [Accepted with modification] SE-0005 "Better Translation of Objective-C APIs Into Swift"

[Douglas Gregor]

The review of SE-0005 "Better Translation of Objective-C APIs Into Swift" ran from January 22...February 5, 2016, with the discussion continuing long afterward. We were thrilled with the scope and depth of the community response to this proposal. The proposal is accepted with some significant modifications, detailed below. The proposal document has been updated at:

  https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md

as have the automatically-generated results for Cocoa APIs:

  https://github.com/apple/swift-3-api-guidelines-review


Most of the modifications to the proposal involve tracking changes to the Swift API Design Guidelines (SE-0023), especially:

* The Clang importer will "split" the first selector piece of a method before the last preposition, producing a base name (the words that precede the last preposition) and an argument label for the first argument (the preposition and the words that follow it). For example, the following Objective-C method:

    - (void)exchangeSubviewAtIndex:(NSInteger)index1
                withSubviewAtIndex:(NSInteger)index2

  will be imported as

    func exchangeSubview(at index1: Int, withSubviewAt index2: Int)

* The Clang importer will change enum cases to lowerCamelCase

* The Clang importer will lowercase initialisms at the beginning of non-type identifiers (e.g., "var UTF8String" becomes "var utf8String")


One significant part of the proposal was the removal of the "NS" prefix from Foundation APIs in Swift. This name change was considered problematic for several reasons, the most-often-cited one being that the reference-semantic nature of many Foundation types conflicted with the Swift standard library's value-semantic types. The "NS" prefix removal part of this proposal has been removed from the accepted proposal. A revised version of this will come back as its own proposal, taking into account the feedback received.

Another interesting aspect of the discussion centered on the naming of methods in delegates. It was observed that the naming of Cocoa delegates isn't captured in the Swift API Design Guidelines. There are a number of potential solutions, including extending the guidelines or [more Clang importer heuristics](http://thread.gmane.org/gmane.comp.lang.swift.evolution/4178/focus=5258). We consider this to be an important but separable problem, so we consider this a reasonable follow-up investigation and won't try to tackle it within this proposal.

Thank you!
Doug Gregor
Review Manager