[swift-users] Swift4/iOS question

[Slava Pestov]

> On Aug 28, 2017, at 1:58 PM, Travis Griggs via swift-users <swift-users at swift.org> wrote:
> 
> If I need to take this question elsewhere, please point me to the right list.
> 
> 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.
> 
> There are two things that the importer is trying to commonly change that I’m curious about:
> 
> 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?

There was a change in Swift 4.0 to make @objc inference narrower in scope. See https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md <https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md> for a description of the change and rationale.

> 
> 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.
> 
> 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?

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.

Slava

> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170828/fdc665ee/attachment.html>