> On Oct 19, 2016, at 10:53 AM, Douglas Gregor <[email protected]> wrote: > >> >> On Oct 19, 2016, at 10:37 AM, Joe Groff <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> On Oct 19, 2016, at 9:35 AM, Douglas Gregor via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>>> On Oct 19, 2016, at 4:53 AM, Jay Abbott <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Ok, good to know that's just a bug. But I still think that implicit @objc >>>> should be removed. >>> >>> Oh, I agree that implicit @objc should be removed. I suspect it’s >>> responsible for a nontrivial amount of code bloat and unnecessary >>> Objective-C selector collisions. >>> >>>> For bridged classes with obj-c-specific interfaces (for example a method >>>> that takes a selector), it would be better if the Swift-side interface was >>>> forced to make a Swifty interface that hides it. This way, the people >>>> maintaining an interface have to either a) write a wrapper with a Swifty >>>> interface; or b) explicitly cop out and use @objc and inform their users >>>> that they may also have to do the same in some situations; or c) persuade >>>> their employers to let them port the whole thing to pure Swift, which >>>> sounds like a lot of fun and is probably what they really want to do :D. >>> >>> I don’t quite view explicit @objc as a cop-out—it’s a useful tool to limit >>> the amount of glue code one needs to write. >>> >>>> I'm not really sure how this works though, at what level this is applied? >>>> Maybe it's more to do with the default build settings in Xcode than Swift >>>> itself? I just would rather see Swift stand alone by default. >>> >>> I think it’s a Swift language change: we should only infer ‘@objc’ when the >>> API >>> >>> * Overrides of an @objc API, >>> * Satisfies a requirement of an @objc protocol, or >>> * Uses a Swift feature that requires the Objective-C runtime (e.g., >>> @NSManaged, @IBAction, currently ‘dynamic’ although that feels wrong to me) >> >> It might also be nice if referring to a method with #selector automatically >> tried to make it @objc. > > It might, although I don’t love the impact on the implementation: we either > end up creating one-off categories associated with the references to > non-@objc methods or our type checker has to process function bodies to > answer the question “is this method exposed to Objective-C”?
I don't think Sema necessarily needs to be involved. We could collect the full set of ObjC methods we need to emit for a class in a module and defer building a single category or class method table to IRGen time. -Joe
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
