<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><blockquote type="cite" class="">On Oct 25, 2017, at 10:27 AM, BJ Homer <<a href="mailto:bjhomer@gmail.com" class="">bjhomer@gmail.com</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>FWIW, I filed a Radar last year on this (<a href="rdar://29623107" class="">rdar://29623107</a>)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">If the ‘tag’ property is the only reason to keep AnyObject dispatch, I don’t think it’s worth its weight in the language.</div></div></div></blockquote><br class=""></div>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).<div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></body></html>