Rule request: explicit access control level

[jdmarshall90]

See title

I know there is a rule for top level ACL declarations, but one for all declarations would be nice. This would probably be opt-in, as it would mostly be useful by frameworks and not applications.

[masters3d]

Do you have any examples on how explicit non top level declarations would benefit from this requested rule?
The use case from the top level ACL rule is frameworks.

[jdmarshall90]

I don't have any specific examples; this is just more of a personal preference that I like to follow when developing frameworks. It gives more context to anything that you're looking at within the library.

[mshibanami]

+1 because I'm a fan of this opinion:

Because default access levels vary across languages, and many people program in more than one language. It's easy to become confused, either as the author or as someone reading the code later, thus explicit is nicer to deal with than implicit.

[marcelofabri]

@mshibanami but adding them to the top level declarations should be enough to cover that case

[mshibanami]

@marcelofabri

internal class Hello {
    let v = "world"
}

In this case, I think it would be nice if SwiftLint warns me about v doesn't have a explicit access modifier. But it seems that explicit_top_level_acl doesn't work so.

I'm sorry if I misunderstood.

[marcelofabri]

That rule won't trigger a violation because it only validates top level declarations (as Hello in your example).

I actually got your point now. Sorry for adding noise to the conversation.

[joseprl89]

+1 to this. I've seen many Swift codebases that neglect using ACLs in the internals of a class/enum/struct. I'm unsure why this is so pervasive specifically on iOS, but I'd prefer to ensure that my team does not neglect something as crucial as class encapsulation.

My concern on class encapsulation is due to Swift defaulting to internal, and as opposed to Java where that's package protected, internal means your whole target can see that field.

In summary, adding this rule would improve the health of any codebase that opts in, so I'm a bit surprised it's not already baked in.

[jpsim]

@joseprl89 since you appear to feel strongly about this, perhaps you're motivated enough to contribute this rule to SwiftLint yourself? I'm happy to provide guidance if you get stuck.

[joseprl89]

@jpsim I had some time that I could chip into it, please review #1966 and let me know if I missed anything 👍

[jpsim]

Done in #1966.