[swift-evolution] [Review] SE-0160: Limiting @objc inference

[Charles Srstka]

> On Mar 24, 2017, at 12:09 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I'm actually not worried about methods so much as properties. KVC is completely untyped on the Objective-C side, and there are several different mechanisms there which use KVC with poorly validated external strings, like bindings, sort descriptors, and predicates. Tons of migration errors are going to escape into production if we do this,
> 
> We can avoid these by migrating conservatively (have the migrator add @objc everywhere it’s inferred in Swift 3).
> 
>> and undetectable mistakes are going to continue on an ongoing basis. 
> 
> … but what you say above is definitely true: the error of omission of @objc will cause breakage for these cases. 

This might be a temporary situation, though: is there any reason, especially given that there’s now a “compilation” process for .xib files, that the format couldn’t be updated to be able to connect to native Swift code? We’d need to add some native implementation of ‘dynamic’ and some equivalent to KVO, but those aren’t insurmountable obstacles for the future. If this eventually happens, the errors of omission will prove to be temporary. And in the meantime, code could probably even be added to the .xib compiler to warn when non- at objc things are referenced.

>> you already have to specify `dynamic` to avoid optimizations;
> 
> Conceptually, ‘dynamic’ is orthogonal to ‘@objc’. In today’s implementation, we can only implement ‘dynamic’ via the Objective-C runtime, hence this proposal’s requirement to write both.

The prospect of eventually having a Swift-native implementation of ‘dynamic’, thus enabling the above, is what pushes me over the fence to +1 on this proposal.

Charles