> On Mar 22, 2017, at 7:50 AM, Michel Fortin via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
