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

Brian King brianaking at gmail.com
Thu Jan 5 11:30:15 CST 2017


+1, I really like the consistency. There's still one potential
inconsistency that I think could be changed to improve things

> Overriding of declarations introduced in class extensions
>
The inference of @objc inside extensions in Swift 3 is more than visibility
to the Obj-c runtime, it also infers `dynamic`. This proposal appears to
retain that, since `@objc` in an extension would allow override via message
dispatch, where as `@objc` in a class declaration would only make the
selector available to the obj-c runtime and retain table dispatch.

Does it make sense to remove the `dynamic` inference too? This would force
all extension methods that can be overridden to be declared `@objc
dynamic`. This clarifies the purpose of @objc since it only manages Obj-C
visibility, and does not modify dispatch behavior.

I know this departs from my previous "NSObject should stay dynamic"
argument earlier, but I was mostly arguing for consistency. Since it is
clear that dynamic behavior should be opted into, I think forcing an
additional `dynamic` keyword seems to make sense. Some developers may rely
on this implicit `dynamic` behavior and encounter issues if a future
version of swift allows overrides in extensions via table dispatch.

Brian King
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170105/5bb24448/attachment.html>


More information about the swift-evolution mailing list