> On Aug 28, 2017, at 1:58 PM, Travis Griggs via swift-users 
> <swift-users@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Reply via email to