<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 29, 2016, at 14:17, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 29, 2016 at 4:15 PM, Matthew Johnson <span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jun 29, 2016, at 4:07 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><blockquote type="cite" class=""><div class=""><br class="">On Jun 29, 2016, at 14:03, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 29, 2016 at 3:15 PM, Jordan Rose via swift-evolution<span class=""> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class=""> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br class=""><br class="">> On Jun 29, 2016, at 13:13, Jose Cheyo Jimenez <<a href="mailto:cheyo@masters3d.com" target="_blank" class="">cheyo@masters3d.com</a>> wrote:<br class="">><br class="">> I know this might be have been brought up before but<br class="">><br class="">> why not just disallow the “private" keyword for top level types, extensions etc.<br class="">><br class="">> A fixit could change top level `private` to `fileprivate`.<br class="">><br class="">> I think this is a little less confusing since effectively this is what is happening in the background.<br class=""><br class=""></span>That doesn’t fix anything for inner types, so it’s a lot less important than the rest of the amendment.<br class=""><br class="">There actually is an answer to this, which is that the core team expects 'private' to be the common keyword, and therefore it’s better if you can use it at the top level and ignore ‘fileprivate’ altogether in most programs.<br class=""></blockquote><div class=""><br class=""></div><div class="">On second thought, wouldn't all of this be inapplicable if `private` literally meant visibility *only* within the current declaration, and neither outside it nor inside any nested types, etc.?</div></div></div></div></div></blockquote><br class=""></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">Yes, but that's not very useful:</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div><blockquote style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class="">public struct Foo {</div><div class=""> private var value: Int = 0</div><div class=""> public func test() {</div><div class=""> print(value) // error</div><div class=""> }</div><div class="">}</div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">I suppose you could say that nested<span class=""> </span><i class="">types</i> are different from nested<span class=""> </span><i class="">functions,</i> but then we start getting complexity in a different direction. And it still doesn't fix the default access within a private type.</div></div></blockquote><div class=""><br class=""></div></span><div class="">And some of us wouldn’t like that direction which means we may not end up with a solution that makes more people happy anyway at which point we’re back where we started.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Looking back on SE-0025, the problem is that the proposal itself has no details that even come close to resolving any of these differences. The only thing that came up for discussion and was agreed to was that `private` should mean something "visible only within that lexical scope." None of this is close to settled and we're probably better off actually debating this in a real proposal.</div></div></div></div></div></blockquote><br class=""></div><div>"Lexical scope" includes both nested types and nested functions.</div><br class=""></body></html>