> * 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. 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. > * Is the problem being addressed significant enough to warrant a change to > Swift? The more Swift code there is in a project, the more important this change will be. > * Does this proposal fit well with the feel and direction of Swift? It will make semantics more predictable. > * If you have you used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? A few years ago I wrote a bridge between D and Objective-C. I actually made two versions: one was based on D templates and generated a lot of thunks, and the second was integrated in the compiler and generated no thunks at all. The first one was creating bloated binaries in addition to being very slow to compile, while the second was very lean as it was mostly an Objective-C compiler using the D syntax. I'm not expecting improvements of the same magnitude here, but emitting less unnecessary glue code is always a good thing. > * How much effort did you put into your review? A glance, a quick reading, or > an in-depth study? Quick reading of the proposal. -- Michel Fortin https://michelf.ca _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
