<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 5:30 PM, 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" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 29, 2016 at 5:25 PM, Matthew Johnson<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>></span><span class="Apple-converted-space"> </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;"><div style="word-wrap: break-word;" class=""><br class=""><div class=""><div class=""><div class="h5"><blockquote type="cite" class=""><div class="">On Jun 29, 2016, at 4:30 PM, Xiaodi Wu 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 dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 29, 2016 at 4:15 PM, Jordan Rose<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:jordan_rose@apple.com" target="_blank" class="">jordan_rose@apple.com</a>></span><span class="Apple-converted-space"> </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;"><div style="word-wrap: break-word;" class=""><span class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 29, 2016, at 14:12, 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 4:07 PM, Jordan Rose<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:jordan_rose@apple.com" target="_blank" class="">jordan_rose@apple.com</a>></span><span class="Apple-converted-space"> </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;"><div style="word-wrap: break-word;" class=""><span class=""><br class=""><div class=""><blockquote type="cite" class=""><div 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="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class="Apple-converted-space"> </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></span><div class="">Yes, but that's not very useful:</div><div class=""><br class=""></div><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><div class="">public struct Foo {</div><div class=""> <span class="Apple-converted-space"> </span>private var value: Int = 0</div><div class=""> <span class="Apple-converted-space"> </span>public func test() {</div><div class=""> <span class="Apple-converted-space"> </span>print(value) // error</div><div class=""> <span class="Apple-converted-space"> </span>}</div><div class="">}</div></blockquote><div class=""><br class=""></div><div class="">I suppose you could say that nested<span class="Apple-converted-space"> </span><i class="">types</i> are different from nested<span class="Apple-converted-space"> </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><div class="">Let me offer a principled rule: if I write `private var foo`, then `foo` is invisible at such places within the declaration where writing `private var bar` at the same place would cause `bar` to be visible where `foo` is not or vice versa.</div></div></div></div></div></blockquote><br class=""></div></span><div class="">I’m sorry, I don’t understand. </div><div class=""><br class=""></div><div class="">Stepping back, though, this part of the proposal<span class="Apple-converted-space"> </span><i class="">was</i> discussed back when it was first going through, and it was settled (after some disagreement and discussion) that pure lexical scoping was the best choice.</div></div></blockquote><div class=""><br class=""></div><div class="">I entirely misunderstood that part of the debate. I had thought the gist of the discussion was that SE-0025 itself was an explicit break from purely lexical scoping, that the proponents of pure lexical scoping were arguing against its adoption, and that its acceptance by the core team was a move away from purely lexical scoping.</div><div class=""><br class=""></div><div class="">Let me see if I can rephrase the difficulty as I perceive it. I had thought that this was an equivalent formulation of the problem that you are addressing with the amendment. The interpretation of `private` as a purely lexical scope results in the scenario as follows:</div><div class=""><br class=""></div><div class="">1. I declare `private var foo`</div><div class="">2. There are places in code where `foo` is visible but where its access level cannot be uttered (e.g., within a nested type, `foo` is not private to that nested type, but it is more narrow in scope than fileprivate, internal, or public)</div><div class=""><br class=""></div><div class="">Your proposal is to allow `fileprivate` to be used in place of the unutterable access level. This seems like a hack. The necessity for it would go away if we stipulated `private` to exclude all places in code where `foo` is visible but where its access level cannot be uttered.</div></div></div></div></div></blockquote><div class=""><br class=""></div></div></div>You have this wrong. It is not that you declare `private var foo` and then in specific places it is visible but you can’t utter its access control. </div><div class=""><br class=""></div><div class="">The problem is when you use `private` on any construct which introduces a scope that contains further declarations. You cannot utter the default access control for the members of that scope. Here are examples:</div><div class=""><br class=""></div><div class="">private struct S {</div><div class=""> <span class="Apple-converted-space"> </span>var foo: Int</div><div class="">}</div><div class=""><span class=""><div class="">private class C {</div><div class=""> <span class="Apple-converted-space"> </span>var foo: Int</div><div class="">}</div></span><div class=""><div class="">private enum E {</div><div class=""> <span class="Apple-converted-space"> </span>var foo: Int { return 42 }</div><div class="">}</div><div class="">private extension S {</div><div class=""> <span class="Apple-converted-space"> </span>func bar() {}</div><div class="">}</div></div></div><div class=""> </div><div class="">In all of these examples `foo` and `bar` are visible within the top level scope, but not outside the file.</div></div></blockquote><div class=""><br class=""></div><div class="">Sorry, yes, that is one problem. The related problem I was trying to describe was this:</div><div class=""><br class=""></div><div class="">```</div><div class="">public struct A {</div><div class=""> private var foo: Int</div><div class=""> internal struct B {</div><div class=""> // I cannot utter the access control for `foo` here</div><div class=""> // and there is nothing I can declare here to be visible</div><div class=""> // exactly where `foo` is visible</div><div class=""> }</div><div class="">}</div><div class="">```</div></div></div></div></div></blockquote><div><br class=""></div><div>Access control is never uttered at *usage* sites. It is uttered at *declaration* sites. By definition of scope-base access control you are not going to be able to utter the precise visibility level of some visible declarations at the *usage* sites. I don’t see why this is a problem. It is utterability at *declaration* sites that is important.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><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;"><div style="word-wrap: break-word;" class=""><div class="">In this case that happens to correspond to `fileprivate` which is probably why Jordan selected that keyword. In cases where these are not top level declarations, but nested within a scope these will be visible within that scope, but not at the top level of the file. In *no* case does the unutterable access level correspond to *internal* which is probably why Jordan did not suggest using that.</div><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">-Matthew</div></font></span><span class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class=""> </div><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;"><div style="word-wrap: break-word;" class=""><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">Jordan</div><br class=""></font></span></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></span></div></blockquote></div></div></div></div></blockquote></div><br class=""></body></html>