Rule Request: strict_accessibility_modifier

New Issue Checklist

• Updated SwiftLint to the latest version
• I searched for existing GitHub issues

New rule request

strict_accessibility would warn where the current accessibility modifier was less restrictive that it could be, given the rest of the codebase.

By enforcing accessibility strictly, declarations allow inference about how the code is used, as opposed to how it could be used.

For example, consider

class Foo {
    var bar: Int = 0
}

here bar is visible as internal by default, but if it is never actually accessed outside its own class, then it could equally be declared as:

class Foo {
    private var bar: Int = 0
}

This makes intent clearer.

This would presumably need to be an analyzer rule.

1. Why should this rule be added?

Enforcing accessibility as tightly as possible makes intent clearer, and can potentially help the compiler.

3. Provide several examples of what would and wouldn't trigger violations.

Triggering Violations:

↓class Foo {
    // if Foo can safely be private
}

↓public class Foo {
    // if Foo can safely be internal
}

class Foo {
    // if bar can safely be private
    ↓var bar: Int = 0
}

public class Foo {
    // if bar can safely be internal
    ↓public var bar: Int = 0
}

Non-Triggering Violations:

Exactly as the triggering violations, but where the rest of the code determines that Foo or bar must be internal, or private, or whatever.

4. Should the rule be configurable, if so what parameters should be configurable?

Possibly configurable for which modifiers should be reported on. For example, warn me about public's, but don't warn me about internal's - I'm not sure I can see a use case for that though.

5. Should the rule be opt-in or enabled by default? Why?

Analyzer rule, so automatically opt-in I believe.

The issue names no implementation files, tests, or entry points; begin by locating SwiftLint's existing analyzer-rule infrastructure and comparable rules. Define how usage analysis determines the narrowest safe accessibility modifier, then document triggering and non-triggering cases and verify the rule's behavior against those examples.