[swift-evolution] [Proposal draft] Limiting @objc inference

Alexis abeingessner at apple.com
Fri Jan 6 16:56:20 CST 2017


I’m a big fan of making @objc less implicit — I’ve frequently been left wondering when it’s actually necessary or not. I think the standard library kinda just uses it haphazardly in its bridging stuff, leaving me to wonder when it actually does anything (this is probably due to how things once worked in the Long Long Ago). 

I don’t consider my opinion to be too valuable here though, as someone who’s never really done meaningful ObjC work.

What I do have a stronger opinion on is that I’m pretty scared about implicitly breaking tons of code in late-binding ways. I’d be more sympathetic to this if we hadn’t declared source stability, but we have, and it doesn’t seem like this breakage meets the bar. Especially since there's a 100% safe migration solution we can implement, if I’m understanding correctly. Adding @objc everywhere it was being inferred seems fairly reasonable to me. This means no immediate benefits for existing code bases, but it still means:

* All new code bases will benefit.

* Old code bases will have a very clear opportunity to audit, if they deem it worth their time. Realistically they probably won’t, but it’s not like their code will be any slower/bloated than it was.




More information about the swift-evolution mailing list