[swift-evolution] access control proposal

[Matthew Johnson]

I agree that you can concoct arbitrarily complex scenarios and a line must be drawn somewhere.  IMO the best place to draw the line is when you start considering something that is not super straightforward to explain and is not a natural extension of the obviously necessary access modifiers.  

IMO ‘scope’ passes this test and all of the complex counter-examples do not.  It is the logical conclusion of a simple narrowing of visibility from “everyone” to “module” to “file” to “scope”.  It is simple to explain and understand.  Those who don’t like it don’t need to use it.  Anything more complex is unlikely to pass such a test.

Matthew

> On Dec 14, 2015, at 10:52 AM, David Owens II <david at owensd.io> wrote:
> 
> Let’s take this it’s next logical conclusion: I have two types that need to access each other’s members for some significant performance gain. Let’s call these types A and B. Now, A also needs access to the inner members for C for the same reason (but note that B does not). I currently have other related types all in the same file, let’s say D and E.
> 
> Now, all members should be “local” to the types, but remember, A needs to access B's and C's members and the other types do not. Also, I can’t simply move the them to different files because they have non-overlapping “local” usage requirements. So do I need to create a “local friend” modifier so only particular types can access the inner details?
> 
> There’s a line somewhere where complexity becomes more burdensome. I’m not sure if “local” is that line, but I absolutely do know that “local friend” is across that line (because of course we’ll need private friend and internal friend modifiers as well…).
> 
>> I imagine physical layout like this is not uncommon in Swift code.  This does not necessarily mean you want these extensions to see implementation details of each other.  By adding a ‘scope’ access modifier we are able to properly hide these implementation details regardless of physical layout.  
> 
> As mentioned above, what if you only want to make them available to some of the extensions?
> 
> -David
> 

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