Avoid specifying access control modifiers on extension level

[pwetrifork]

It's less confusing when access control is specified on a member level, i.e. fileprivate func/var member instead of private extension Type { ... }.

[wnagrodzki]

Access control modifiers should not be specified on extension level:

private extension MyType {
    func method() {
        // code using helper()
    }
    func helper() { ... }
}

But on member level:

extension MyType {
    fileprivate func method() {
        // code using helper()
    }
    private func helper() { ... }
}

This is to introduce distinction between members that should be visible from different types in the same file and those which should not. (private extension has the same result as fileprivate extension where all members end up being fileprivate).

[wnagrodzki]

@pwetrifork @moskacz Do you think it is good enough to append to our guidelines?

[pwetrifork]

My original motivation was just to make the access level of each member immediately obvious, particularly in longer extensions where scrolling might be required otherwise.

The suggestion to use private/fileprivate split may lead to confusion in some scenarios. For example, when the whole extension is a helper to be used by the core implementation or another extension on the same type in the same file, there is no difference between private and fileprivate from language point of view. In this case, the intention for using different access modifiers might not be clear for a reader who is not familiar with our guidelines.

[Moskacz]

@wnagrodzki OK for me