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

[Slava Pestov]

> On Mar 22, 2017, at 10:55 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> * What is your evaluation of the proposal?
> 
> I'm going to have to come down on the "no" side on this one.
> 
> 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, and undetectable mistakes are going to continue on an ongoing basis. 
> 
> Have we explored alternate implementations? For instance, when the compiler can statically determine all of the call sites for an `@objc` member, could we emit *only* an implementation with the Objective-C calling convention and call that directly from Swift?

This would incur bridging overhead for collections I believe. We really do want to use the Swift calling convention whenever we know the method is defined in Swift, even if happens to be exposed to Objective-C. It would be unfortunate if there was an unpredictable performance cliff encountered because of @objc inference.

> Have you evaluated applying different rules to methods and properties? Have you considered a deprecation cycle (for instance, having Swift 4 thunks log a warning that they're going away in Swift 5)?

I’m not sure how this could work. If we emit an unconditional warning on every method that has an Objective-C compatible signature but is not marked as @objc, how would the user acknowledge the warning and say “OK, I don’t really want inference here?” Would the only way to opt out of the warning be to write @nonobjc everywhere?

> Or is the real motivation that, code size issues aside, you think these members ought to be explicitly marked `@objc` for philosophical reasons? If so, how many times do you want people to say so? You already have to explicitly inherit from an `@objc` base class; you already have to specify `dynamic` to avoid optimizations; now you also have to mark individual members `@objc`? Would you like the request for bridging notarized and filed in triplicate?

The ‘accidental selector name clash’ argument is a good one I think; if you’re designing a pure Swift class that happens to inherit from NSObject, it might be confusing to a user if they define methods named foo(_: Int) and foo(_: String) and get a compiler error.

It would be interesting to get some more data on the size overhead of @objc thunks from real codebases, but I think the difficulty there is ascertaining which thunks are ‘required’ and which ones are not (which of course is also the core of your objection to the feature, if I understand; if we could perfectly determine which thunks were needed statically, the migration story would be far less of a concern).

Slava

> I can understand the impulse to require it explicitly on `public` members, but on the other hand, if you *do* accidentally publish a member as `@objc`, what's the harm? Is there any non-breaking change you can make to a `@nonobjc` method which wouldn't be legal on an `@objc` one? Or can you just deprecate the `@objc` version and move on?
> 
> Overall, I think this is far too bureaucratic, and I'm not convinced that either the technical or the theoretical justification is compelling. Maybe you've eliminated some of the possibilities I've suggested or there are negative effects I don't understand, but right now, I don't see it. 
> 
>> * Is the problem being addressed significant enough to warrant a change to Swift?
> 
> I'm uncertain. 
> 
>> * Does this proposal fit well with the feel and direction of Swift?
> 
> It fits with certain goals, like making public APIs explicit, but not with others, like avoiding boilerplate. 
> 
>> * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 
> I haven't used anything with such deep foreign-language bridging as Swift. 
> 
>> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> Quick reading during a hockey game, so please forgive any oversights. 
> 
> 
> Sent from my iPad
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution