[swift-evolution] Pitch: Deprecate/remove AnyObject method dispatch

Charles Srstka cocoadev at charlessoft.com
Wed Oct 25 11:15:24 CDT 2017


> On Oct 25, 2017, at 10:27 AM, BJ Homer <bjhomer at gmail.com> wrote:
> 
> That would be a Cocoa-side change, since UIView, NSView, NSMenuItem, NSCell are all Cocoa-level objects. (I’m not aware of any other type that would be commonly passed as a ‘sender’ parameter and would have a tag.) That change wouldn’t go through Swift-Evolution.
> 
> So in theory, if Swift 5 decides to get rid of the AnyObject dispatch, the Cocoa teams at Apple could work around that by introducing “@objc protocol IntegerTagged”, and introducing a migrator pass to look for '(sender as AnyObject).tag’ and rewrite it as `(sender as! IntegerTagged)?.tag.

The Swift team and the Cocoa team communicate with each other, though? I ask because there have been some changes to the Cocoa frameworks in the past (see below) that were clearly made in the interest of improving Swift interop, and also because the Swift bug tracker has a field for Radar report IDs.

FWIW, I filed a Radar last year on this (rdar://29623107 <rdar://29623107>)

> If the ‘tag’ property is the only reason to keep AnyObject dispatch, I don’t think it’s worth its weight in the language.

Potentially there could be more; what would need to be done would be to dig through the documentation and find all the methods that returned untyped proxy objects. NSTreeNode’s arrangedObjects *was* one of these until very recently; prior to 10.13, it returned an ‘id’ which responded to a couple of methods described in the documentation. They finally changed it in High Sierra to return an NSTreeNode, because using it had been very obnoxious in Swift. My intuition is that there may be more APIs like this in the frameworks that return proxy objects like this, although I can’t remember any specifically off the top of my head right now. Any such methods would need to be fixed, though, because without the AnyObject behavior, these objects would become completely unusable—even the “extension on NSObject” trick isn’t guaranteed to work, since objects typed ‘id’ are not guaranteed to be derived from NSObject (they could, for instance, be NSProxy).

Charles

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


More information about the swift-evolution mailing list