+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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
