[swift-evolution] SE-0025: Scoped Access Level, next steps

Chris Lattner clattner at apple.com
Tue Mar 29 13:08:38 CDT 2016


> On Mar 28, 2016, at 6:38 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
>>> On Mar 28, 2016, at 18:20, Matthew Judge <matthew.judge at gmail.com> wrote:
>>> 
>>> There are two different  questions that we keep bouncing back and forth between. Given:
>>> 
>>> class Outer {
>>>   private var outerVar: Int
>>>   class Inner {
>>>       private var innerVar: Int
>>>   }
>>> }
>>> 
>>> Is outerVar visible inside Inner? To me this seems 'obvious'... Yes.
>>> 
>>> Is innerVar visible to Outer? The answer to this impacts what I think the access modifiers should be called.
>> 
>> Fair question. Data:
>> 
>> - C++: no, but the language has "friend".
>> - Java: yes
>> - C#: no
>> 
>> - Ruby: no, but "private" means something slightly different
>> - D: yes, but "private" means something more like Swift's current "private"
>> 
>> - Kotlin: no
>> - Scala, Python, Go, Rust, Objective-C, Smalltalk: either no access control or no nested types, AFAICT
>> 
>> So it's tending towards "no" but it's not as consistent. I agree that if we pick "yes" then (for example) "scoped" would be a confusing name.
> 
> No is the only answer that is consistent with Swift’s other access modifiers - i.e. strictly based on lexical scope.  My opinion is that we should stick to strict lexical scoping.  It is a simple and consistent principle that is easy to understand and explain.

+1

-Chris


More information about the swift-evolution mailing list