[swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Vladimir.S]

On 07.10.2017 20:17, Nevin Brackett-Rozinsky via swift-evolution wrote:
> Two weeks ago I had a fairly strong opinion about “private extension” behavior. After following this discussion, I now 
> have no opinion on the matter.
> 
> I would summarize the points on both sides as follows:
> 
> For the change:
> • It is surprising to many people that members of a private extension are implicitly fileprivate. > • There is currently no way to make an extension whose members default to private.

I'd add this:
* Current rule for 'private extension' can lead to bugs, when you expect that private methods will be 'true' private but 
they are fileprivate, so could be called from not-expected code in the same file. Inverse situation(when you need 
fileprivate but 'private extension' means 'true' private) - can't cause bugs, you'll be notified by the compiler if you 
need a 'wider' access level.
* The change will make the access-control rule for extensions simpler, not harder to understand.
* 'fileprivate' access level for methods in extension will be used by *intention*, not just because "this is how 
'private extension' works". If I understand correctly, it is not the 'fileprivate' *keyword* we want to see less, but 
the fileprivate *access level*, which should be rare and intentional.

> 
> Against the change:
> • The proposal is source-breaking.
> • The proposal makes “fileprivate” more common.

It depends on what most of Swift developers *mean* when writing 'private extension' - if they actually need 'fileprivate 
extension' - then yes, we'll see it more in code. But if in most cases the *intention* is to have a bunch of 'true 
private' methods - we'll have a small number of 'fileprivate extension'.
But in any case, what is the problem with this? If developer *needs* fileprivate access level for methods in extension - 
this will be clearly stated in code, not hidden under the cute title of 'private extension'

> • A private extension and a (top-level) private type both currently have implicitly fileprivate members. The proposal 
> breaks that symmetry.

Is it really good symmetry?
By definition, the rule for applying the access level to type is differ from the rule for extension. Here all symmetry 
already broken and we have 2 separate rules. And from my point of view, having a symmetry in *this particular* case is a 
bad thing, it can lead to wrong assumptions. Don't you want to apply the same 'symmetry' rule for the code below ? :

public class C {
     var i = 10
}

public extension C {
     func j(){}
}

,as you understand 'i' is internal, while 'j()' is public. So this could be a dangerous assumption.


> 
> Notable questions:
> • Currently “open” cannot be applied to an extension at all, should we allow it?

Probably. But this should be a separate pitch/proposal.

> • Might we ever want to allow nested (non-top level) extensions, and if so how should access levels on them work?

Not sure if we need them, this is also a subject for separate pitch/proposal.
But if the rule for applying the access level for extension will be as currently(I don't believe we'll change it soon) - 
nested extensions should work the same "the access level keyword stated before the 'extension' keyword will be virtually 
copy&pasted to the beginning of each method declaration inside extension and then resolved", IMO this is a most clear 
rule we can have *in case rule for extensions is differ from rule for type".

Vladimir.

> 
> Nevin
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>