[swift-evolution] access control proposal

[John McCall]

> On Dec 9, 2015, at 9:16 AM, Matthew Johnson <matthew at anandabits.com> wrote:
>> I’m still not completely convinced about the need for this level of access control, but I really like “local” as the keyword for it.
> 
> I don't think we *need* it, but it does allow for more explicit statement of intent in code and enforcement of that intention by the compiler.  That is almost always a good thing IMO as long as it doesn't make your code excessively verbose.  In this case we would be replacing 'private' with 'local' so no verbosity would be added.  
> 
> I don't think it's a really high priority addition relative to a lot of other things, but it seems to me like a relatively low cost feature with few if any downsides.  Programmers who don't want to use it don't have to.  I wonder if there are any strong arguments against adding it other than it making the language ever so slightly larger.

Right, I think that’s the tension here: there’s clearly at least *some* value in it as an access specifier.  The concern is that it heavily overlaps with “private”, because when people write larger types, they’re likely to do so in a single file.  That means it’ll introduce a lot of confusion about which one to use, and you’ll probably see poorly-styled code bases that use them interchangeably.  This will be amplified by the fact that “private” is the one people are familiar with in other languages.

In other words, I can definitely see why it’s a good idea for *code*.  I am uncertain whether it is a good idea for *the language*.

> The 'local' keyword does seem pretty good.  I like it much better than 'classified'.  My only question about it is whether some programmers might confuse it with local variables in a function.

We should be disallowing access modifiers in function contexts anyway.

John.