[swift-evolution] [Accepted with modification] SE-0005 "Better Translation of Objective-C APIs Into Swift"
Radosław Pietruszewski
radexpl at gmail.com
Thu Mar 3 17:00:38 CST 2016
Woohoo! This has been a great process discussing all the nitpicks to get it right, and I’m quite happy with the result.
Thanks Doug & all,
— Radek
> On 03 Mar 2016, at 22:57, 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:
>
> 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
More information about the swift-evolution
mailing list