Impact of redundant public when final is explicit

[rnapier]

In many cases, we have classes that would be public if they were in a separate module, but are currently part of the main app. We typically mark these as public final to document their design intent and to simplify moving them into a separate module in the future.

Periphery marks these redundant-public. My question is, given that they are also marked final, is there any cost to being public at the app level? Does this make the compiler work harder, or increase the size of intermediate files? If there's no cost, we would likely turn this analysis off since it's very noisy, though we would still like it for local modules.

[rnapier]

For some expert discussion on this, see https://mastodon.social/@cocoaphony/112729062183695357. Not certain if this alters how this option should work in periphery.

[ileitch]

Provided all of these public classes are also final where necessary, then it looks like removing the public accessibility would not result in any additional compiler optimizations, and they do not introduce any overhead in build times.

I guess it's then down to you to decide whether you find value in redundant public analysis for non-main-app targets vs. reducing the number of warnings. Alternatively, you can exclude all results for just the main-app target with --report-exclude or comment commands. Unfortunately, it's not currently possible to exclude only the redundant public warnings for a single target. Another option is to filter the results yourself manually.

One could argue that Periphery should not report redundant public accessibility warnings for final classes. However I do think this analysis provides some value beyond just the compiler optimizations, as it's helpful to reduce the scope of public interfaces only to what is referenced publicly.