<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 28, 2017, at 1:58 PM, Travis Griggs via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">If I need to take this question elsewhere, please point me to the right list.<br class=""><br class="">I decided to take the dive this morning and give XCode9 beta and Swift 4 a try. I’m tired of not being able to refactor.<br class=""><br class="">There are two things that the importer is trying to commonly change that I’m curious about:<br class=""><br class="">1) Anywhere I’ve linked a UIControl to a method via the addTarget(self, action: #selector(foobar), for: .valueChanged), it now feels that foobar needs to be annotated as @objc. I really liked that so far in my swift journey, I’ve never had to put one of these @objc things in. I think I get what’s going on. My class is a swift class, but is a subclass from UIViewController, an objc class. While apparently, it could infer that subclass methods should be objc callable, they no longer are?<br class=""></div></div></blockquote><div><br class=""></div><div>There was a change in Swift 4.0 to make @objc inference narrower in scope. See <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md</a> for a description of the change and rationale.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">What’s frustrating is that if UIControl just had an action API that used closures instead of the older perform: patterns, I’d just rewrite these as such. But it still doesn’t. So people still make extensions which have to resort to static globals or associated_objects.<br class=""><br class="">2) I have a couple of CALayer subclasses that have a couple different ways of setting/accessing the same thing. I use dynamic vars for those. Once upon a time, someone told me that I needed to make them dynamic for the animation engine to correctly note changes to them. Apparently, those all need to be tagged @objc now. Which seems redundant to me. Are not dynamic vars already implicitly objc anyway? Is the new need to add @objc just for consistency sake?<br class=""></div></div></blockquote><div><br class=""></div>This is also part of SE-0160. The reason dynamic no longer implies @objc is that one day we could make dynamic work independent of the Objective-C runtime, and support it on Linux too for instance.</div><div><br class=""></div><div>Slava</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">_______________________________________________<br class="">swift-users mailing list<br class=""><a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-users<br class=""></div></div></blockquote></div><br class=""></body></html>