[swift-evolution] [Accepted with modification] SE-0005 "Better Translation of Objective-C APIs Into Swift"
howard.lovatt at gmail.com
Thu Mar 3 16:36:49 CST 2016
Just wanted to say how well I think this review went. There was a lot of
feedback and you have handled all the competing opinions skilfully. Thanks,
On Friday, 4 March 2016, Douglas Gregor via swift-evolution <
swift-evolution at swift.org> wrote:
> 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:
> as have the automatically-generated results for Cocoa APIs:
> 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
> 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](
> 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
> swift-evolution mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution