I lean towards no as well, but this implies an infinite level of access modifiers: public private(module) // current internal private(file) // current private private(Outer) // all of the rest are the new private private(Inner) private(InnersInner) etc.
The bike shedding has been focused on renaming the current private (and maybe the current internal) and all of the remaining levels will be called private. I don't see private(file) and private(module) as special cases, just the most common ones... along with private(Outer). (Note: private(Outer) and the like aren't meant as proposed syntax and have problems, but hopefully the meaning is clear in context.) > On Mar 28, 2016, at 21:38, Matthew Johnson <[email protected]> wrote: > > >> On Mar 28, 2016, at 8:32 PM, Jordan Rose via swift-evolution >> <[email protected]> wrote: >> >> >>> On Mar 28, 2016, at 18:20, Matthew Judge <[email protected]> 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. > >> >> Jordan >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
