Also consider what would happen if we did allow access control to escalate here: Suppose that code did not emit a diagnostic, then the member is still private because you cannot reference the class outside of file scope. You see, even if we did escalate access control for unannotated members, even if we did that (which we don't) you wouldn't even be able to reap the benefits. It makes no sense.
~Robert Widmann 2016/06/15 18:47、Charles Srstka <cocoa...@charlessoft.com> のメッセージ: >> On Jun 15, 2016, at 8:36 PM, Robert Widmann <devteam.cod...@gmail.com> wrote: >> >> Point 3 is *not* how member lookup applies access control levels to >> unannotated properties of outer structures (see >> https://github.com/CodaFi/swift/blob/fb9f9536a5760369457d0f9c49599415cbc36e07/lib/Sema/TypeCheckDecl.cpp#L1470) >> and makes no sense. They do not default to "internal" when unannotated, >> they default to the highest possible access level they can get given the >> decl they're in. A private structure will necessarily have private members. >> This is the whole point of me raising this issue. If we were to break >> containment we would break the very motivation for this proposal. And if we >> wish to do this to get this feature right, then the proposal needs to be >> amended to include that kind of caveat. > > This isn’t correct. If the outer type is marked “public”, and its properties > are not annotated, those properties will be internal, *not* public, and you > will not be able to see them outside of the module. > > The rule can basically be summed up as “internal by default, unless we can’t > because our enclosing type is more restrictive than internal. Then, be as > visible as the enclosing type is." > > Charles >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
