[swift-evolution] access control

[Ilya Belenkiy]

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

It’s a convention that is not enforced by the compiler. Anyone can break it, accidentally or deliberately.

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

Not if you are in the same file. If you are, you can access anything.

> If you edit the same file you are in effect the class’s author

Not necessarily.

> and therefore should know the intent (or be able to derive it).

but if the API is marked properly, you don’t need derive anything — just look at the declaration. Also, with “local” the compiler catches a mistake while with “private” it is possible to make it. Why do this manually with a huge potential for human error when the compiler can enforce it for you?

> 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.

Because in Java, the compiler enforces one class per file. So you in Java you *are* changing the class itself. If Swift enforced one class per file and one extension per file, there would be no difference, but nobody wants that because it would be very inconvenient.

> On Jan 25, 2016, at 4:32 PM, Thorsten Seitz <tseitz42 at icloud.com> wrote:
> 
> 
>> 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
>