[swift-evolution] access control proposal

[Brent Royal-Gordon]

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

I actually immediately thought of several things you might want:

• You have two logical “groups” of properties and methods in a type, and you want to only permit access within a group. But both groups have stored properties, so they must be defined in the scope of the main type definition.
• You have types nested within your type. You want methods in your own type to have access, but not methods in those nested types.
• Alternatively, you have types nested within your type. You want the outer type to have access to things in the nested type, but not any other type.

I don’t think these are troll proposals. They *are* a little more limited, a little more esoteric, but you could say the same thing about `local` vs. `private`. And in some cases you can emulate some of these with the four access modifiers you want, but again, you could say the same thing about `local` vs. `private`.

>> 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 is not a bad idea. The only potential issue I can see with it is that, if it’s made too general, it might be difficult to construct a Synchronized instance correctly.

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

But it’s not zero-cost. It’s another thing to learn, another thing to think about, another way you have to mentally analyze your code. It has to be balanced against the goal of keeping the language small and simple. And many people, when they do that, find this idea wanting.

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

`local` is going to be equally useless in this context, because MainViewController.swift will almost certainly contain one 9.999KLOC `class` block. Cleaning up is, practically by definition, messy and tiring.

-- 
Brent Royal-Gordon
Architechies