> On Oct 19, 2016, at 9:35 AM, Douglas Gregor via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Oct 19, 2016, at 4:53 AM, Jay Abbott <j...@abbott.me.uk >> <mailto:j...@abbott.me.uk>> 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. -Joe
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
