[swift-evolution] [Accepted with modification] SE-0005 "Better Translation of Objective-C APIs Into Swift"
Howard Lovatt
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,
-- Howard.
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:
>
>
> 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 <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
--
-- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160304/80decb0a/attachment.html>
More information about the swift-evolution
mailing list