[swift-evolution] access control proposal

[Drew Crawford]

> On Dec 13, 2015, at 3:57 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
> 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`.

You're right.  Your examples have convinced me of this point.  There exist non-troll proposals for further access modifiers.

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

I meant zero performance cost.  Of course all features have "cost" if we mean "cognitive overhead".  Type safety for example has a huge cognitive overhead.  Think back to the days of "Bool is not an NSString".  But the benefit of typesafety is large.  

In this case, the cognitive overhead is small, and so is the benefit.  But I think the value-per-unit-cost is similar.  In both cases the compiler helps you not do something very very bad, that is hard to debug in ObjC.

> many people, when they do that, find this idea wanting.

Who?  You?  Then build an argument around that.  I don't know who "many people" are or what their justification is.

My justification is essentially that A) something like Synchronized is a problem nearly everybody has and B) the difficulty of defining a class-based solution in an optimal way.

On B, we seem to agree:

>  it might be difficult to construct a Synchronized instance correctly.

So I can only conclude you disagree about A.  However, I think my A is much stronger than is strictly necessary to demand a language feature.  There are plenty of language features that not everyone uses, so the fact that you don't have a need for it (or even "many people") is not really a counterargument I am able to understand.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151213/85158d27/attachment.html>