[swift-evolution] access control proposal
rjmccall at apple.com
Wed Dec 9 11:38:49 CST 2015
> 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.
More information about the swift-evolution