Default UseAccessLevelOnImports
to false
#2047
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
After the discussion on #2042 (comment), I played a bit more with
InternalImportsByDefault
and the different generator options, got to the following conclusions:import Foo
to some file, whereFoo
is also being imported with an explicitinternal
access-level modifier in the generated code, it will work as long asInternalImportsByDefault
is enabled.InternalImportsByDefault
for the corresponding target inPackage.swift
, you get an"Ambiguous implicit access level for import of 'Foo'; it is imported as 'internal' elsewhere"
error (not a warning). This means that if the code generator plugin(s) begin adding the access level modifiers by default based on how they're built, they could cause source-breakages for users unintentionally.Given all this, defaulting
UseAccessLevelOnImports
tofalse
always for now may be the easiest (and least surprising, from a users' perspective) thing to do, untilInternalImportsByDefault
are enabled by default in a future Swift >6.0 version (as the proposal states), where we can default totrue
again:The rationale behind this is that adding access levels to imports on your code is currently totally optional. If you choose to start adding them explicitly, then it's okay to also have to tell your tooling/generators that they should also add them explicitly. If you don't, they'll keep generating things the exact same way they've been doing it, which is what users of the generator would expect.
Modifications
UseAccessLevelOnImports
tofalse
always.InternalImportsByDefault
from test and executable targets, since it doesn't make a lot of sense to have access level modifiers on imports here anyways as these targets cannot be imported.