[swift-evolution] [Review] SE-0160: Limiting @objc inference
Douglas Gregor
dgregor at apple.com
Thu Mar 30 18:55:57 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'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. Actually, would the changes in this proposal make the `@nonobjc` attribute irrelevant?
>
> 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.
FWIW, I’ve updated the proposal with a much more extensive discussion of the migration story. It incorporates “conservative” and “minimal” approaches, and describes how to do the “minimal” approach well. (It’s backed by a prototype implementation as well; see the Implementation link at the top”)
- Doug
More information about the swift-evolution
mailing list