> On Mar 22, 2017, at 10:55 PM, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > >> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution >> <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
