[swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift

[plx]

My main reaction is the proposed translation is usually an improvement, but the proposal as-written is a bit hand-wavy on how to handle the situations where it doesn’t do a good job.

What I mean is, it is written from a perspective that comes across as “we have a solid-enough understanding of what Swift-y APIs should look like, and this proposal is sketching an automated approach to map Objective-C into that as best as possible; of course, in some cases the automated approach will be insufficient, and in those cases explicit annotations will be called for”.

But, as came up on the API guidelines discussion, there are parts of Objective-C for which there doesn’t seem to be any commonly-agreed-upon “Swift-y” equivalent; the delegate-style APIs are one such obvious case (and my motivating example), but there may be others once the enhanced translation starts seeing real use.

For such “problematic API styles” it’s not really going to be enough to say, for example, “we’ll add explicit annotations to deal with those”, because *what* those annotations *should be* doesn’t seem all that obvious right now; at least for the delegate-style APIs, even the enhanced translations are still wildly out of sync with the Swift API guidelines, and that style will either need to be grandfathered-in or some other form agreed-upon.

To make it concrete, here’s a few from the `UICollectionView*` family:

// IMHO an annoying inconsistency in how the type is incorporated into the 2nd argument’s label:
func collectionView(collectionView: UICollectionView, didEndDisplaying cell: UICollectionViewCell, forItemAt indexPath: IndexPath)
func collectionView(collectionView: UICollectionView, didEndDisplayingSupplementaryView view: UICollectionReusableView, forElementOfKind elementKind: String, at indexPath: IndexPath)

// IMHO an annoying inconsistency between the 2nd and 3rd argument labels:
func collectionView(collectionView: UICollectionView, targetIndexPathForMoveFromItemAt originalIndexPath: IndexPath, toProposedIndexPath proposedIndexPath: IndexPath) -> IndexPath

// IMHO an annoying inconsistency vis-a-vis its 2nd and 3rd argument labels and those from the previous example:
func collectionView(collectionView: UICollectionView, moveItemAt sourceIndexPath: IndexPath, to destinationIndexPath: IndexPath)

…which I’d summarize by first reiterating that these are both:

- nowhere near in accord with the Swift API guidelines
- worse-off for being “partially translated” (the original APIs are verbose but predictable-and-mutually-consistent; these are verbose and neither predictable nor mutually-consistent)

I’m not sure what the right approach for the delegate APIs is — maybe they get grandfathered-in, maybe some Swift-ier form is chosen for them — but I think their presence shows a weakness of the *proposal* at this time: there are API territories for which there is as-yet no agreed-upon ideal translation to some Swift-ier form, and some more-explicit mention of such scenarios seems like it ought to go in the proposal (even if just in the future-steps section).

That’s my 2c at this time 

> 
> On Jan 22, 2016, at 3:02 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hello Swift community,
> 
> The review of SE-0005"Better Translation of Objective-C APIs Into Swift" begins now and runs through January 31, 2016. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md <https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md>
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md <https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md>
> Reply text
> 
> Other replies
>  <https://github.com/apple/swift-evolution#what-goes-into-a-review-1>What goes into a review?
> 
> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md <https://github.com/apple/swift-evolution/blob/master/process.md>
> Thank you,
> 
> -Doug Gregor
> 
> Review Manager
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160124/a5d4b075/attachment.html>