[swift-evolution] access control

[Thorsten Seitz]

> Am 25.01.2016 um 16:12 schrieb Ilya Belenkiy <ilya.belenkiy at gmail.com>:
> 
> I didn’t propose to remove or repurpose the existing “private” access modifier. Instead, I proposed an additional “local” modifier for real data encapsulation. I think that the current “private” modifier is misnamed. It would be much more concise to call it “file internal” or something similar, but it looks like it’s too late to change this now. Both “private” and “local” are useful. One doesn’t have to exclude the other.
> 
>> Yes, it does trade formalism for convenience, but I believe that the tradeoff is reasonable. 
> 
> Both can and should exist in the language. No need for tradeoffs.

I don’t see much of a tradeoff: if you want class private just put nothing else in the file.


>> You already need to maintain some degree of discipline when writing code (you can’t make the compiler to enforce all conventions for you)
> 
> In every other respect, Swift compiler tries to help, except this one. The strong type system and type inference are a big deal. This is a big deal for the same reason.

I don’t understand: the compiler checks whether you have access to a member, so it certainly does help, doesn’t it?


>> Once you embrace idea that all declarations in a single file are closely interdependent (this way or another), file-based access control stops being an issue as you present it. 
> 
> 
> It will still be an issue because there is no way to express the author’s intent on whether something is truly private or can be safely shared with closely related code.

If you edit the same file you are in effect the class’s author and therefore should know the intent (or be able to derive it). When I’m editing a Java class (possibly written by someone else) I also have to check whether I can safely use a private method or whether I’m breaking the inner workings of the class by my changes. No real difference there.

-Thorsten