[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