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

Douglas Gregor dgregor at apple.com
Wed Mar 22 12:29:16 CDT 2017


> On Mar 22, 2017, at 7:50 AM, Michel Fortin via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> * What is your evaluation of the proposal?
> 
> Good. I'll certainly appreciate the added clarity of knowing which methods are exposed to Objective-C.
> 
> Currently, Swift-only apps are bloated by unnecessary Objective-C thunks. The motivation section says that this will reduce the reduce the binary sizes, which is good, but should we expect not emitting those thunks will also reduce by a bit the compilation times? Perhaps not by much, but I do think it will.

I don’t think the effect on compilation time will be significant or noticeable. Although numerous, the thunks are fairly small and straightforward to produce/optimize/code-gen.

> 
> I'm already littering some projects with plenty of `@nonobjc` annotations because I don't need those thunks. This proposal would allow me to make this cleaner. Perhaps the migrator should remove the `@nonobjc` attributes when they become unnecessary.

Yes, it could do that. 

> Actually, would the changes in this proposal make the `@nonobjc` attribute irrelevant?

In practice, it would probably become mostly irrelevant. I suspect it would still find occasional use to suppress a warning about, e.g., a method that “almost matches” an optional requirement in an Objective-C protocol but that is not intended to match.

> 
> I'm a bit worried about the migration though.
> 
> I think it would be reasonable for the migrator to have two settings. A conservative one that adds `@objc ` to all currently implicit `@objc` declarations, to be used when you need to be absolutely certain everything still works. Pruning of extra `@objc` would have to be done manually later, if desired. And the default one that only adds `@objc` when the migrator sees it as necessary.
> 
> I know I would always want to use the default migration setting. But it'd be reassuring to have a safe fallback in case the migration breaks things.

I expect it’ll take some experimentation to get it right.

	- Doug



More information about the swift-evolution mailing list