[swift-evolution] [Proposal draft] Limiting @objc inference

[Jordan Rose]

> On Jan 4, 2017, at 21:36, Charlie Monroe via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I'm personally coming back and forth on this - my code is now 99% pure Swift, so I don't really need @objc declarations aside for:
> 
> - CoreData - which is fairly obvious and @NSManaged will scream if the type isn't @objc-compatible
> 
> - UI - and this is a big part. Unfortunately, I've relied on @objc inference in multiple cases when it comes to binding (macOS). Or to be more precise @objc implied dynamic. So for NSObject subclasses
> 
> var foo: String = ""
> 
> is without further annotations usable with bindings (though IB screams that NSString is expected and it found String). And who has previously dealt with them knows that this change will be hell to debug and discover all the places since Interface Builder usually isn't very helpful in this matter.
> 
> In order for the migration to go smoothly, it would require the IB to do some kind of keyPath validations and add annotations to those places as well. Without it, I can't imagine the transition... IB has been a source of great deal of ObjC -> Swift headaches, I wish there weren't any more.

Good^W Bad news: this never worked. @objc does not imply 'dynamic', so you're just dropping updates on the floor. Unfortunately the bindings system can't detect this case and warn you about it.

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170105/9c786604/attachment.html>