[swift-evolution] access control proposal

[Drew Crawford]

> I mean, look, you’re right. In your case, three access modifiers isn’t enough to prevent this mistake; you need four. But,
> given four, you could provide an example that needs five. Given five, you could come up with one for six. Given N access modifiers, you can write a case where you need N + 1.

Nope.  What we're talking about (what I'm talking about, anyway) is a syntactically scoped access modifier.  There is no N+1 case.  There is no "even more scoped".  There is no inductive case.

I mean, it is possible to write a troll proposal for an access modifier visible to the 3 lines before and after the declaration, or something.  That much I grant.  But troll proposals aside, a scoped access modifier is the quark of the access modifiers; there is no sensible way to go halvsies.

> Actually, for this case, there *is* a way to achieve better safety without additional access modifiers. Create a new file and call it Synchronized.swift:

This is the solution that I ship.  I think if we don't add a new visibility modifier, we should definitely do this in the standard library, because "resource synchronization" is a problem most modern programs have.

This particular implementation is insufficiently general, however--there are more ways to synchronize a resource than on a GCD dispatch queue.  I do agree that a general solution can be constructed out of this example, and reasonable people can disagree about whether adding local or adding a more-general Synchronized is a better solution to this problem.

> My solution is to be careful when I’m writing code.

It is actually *this* statement which is weak to an induction attack.  We can *always* be more careful writing code.  Why do we need typechecking, why do we need integer overflow trapping, why do we need array out of bounds exceptions?  The C developer says they do not need half of Swift because their solution is to be more careful writing code.  The C developer is naive.

But in *this* language, we adopt zero and low-cost abstractions in the name of safety.  A scoped access modifier is a zero-cost abstraction that makes the language safer.  We should adopt it.  If for no other reason, than consistency with the other aspects of the language design.  Either that or we should move integer overflow checks into the standard library for consistency with Synchronized, which I present as a troll proposal.

I mean, I don't know about you, but I get called in to look at projects regularly that have a MainViewController.swift that weighs 10KLOC.  I didn't write it.  I didn't make the mess.  I just want tools to help me clean it up.  'private' is useless in that context, and it's a (sadly) typical context in iOS.