<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=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I <i class="">still</i> don't understand your reasoning here. If a private member can be used in a member function, and in closures inside that member function, why can't it be used in a member type?</div><div class=""><br class=""></div><div class="">I don't have a notion of "immediate lexical scope". Nothing else in Swift is only visible in the "immediate" level of curly-braces.</div><div class=""><br class=""></div><div class="">(This doesn't mean that everything can <i class="">successfully</i> be referenced from an inner scope; for instance, a local type declared in a function cannot capture local variables or 'self'. But there's a technical limitation there, and even <i class="">with</i> that you still find those names via name lookup.)</div><div class=""><br class=""></div><div class="">I am actively against this form of the proposal (regardless of names) and I'm sorry I didn't notice the intent here the first time around.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 28, 2016, at 6:06, Ilya Belenkiy via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="white-space:pre-wrap" class="">Matthew, please take a look at my example with functions (it works today). In terms of scope, it should be the same with classes. I updated the proposal to restrict private to the immediate scope, so with the update, it will be Inner. Please take a look at the proposal. I tried to be very clear about both the meaning and motivation in the proposal example.</div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Mar 28, 2016 at 8:58 AM Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class=""><br class=""><br class="">Sent from my iPad</div><div class=""><br class="">On Mar 28, 2016, at 6:48 AM, Ilya Belenkiy via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="white-space:pre-wrap" class="">Outer</div></div></blockquote><div class=""><br class=""></div>Why Outer? It looks to me like the enclosing lexical scope is Inner, thus innerVar would *not* be visible in Outer, it would only be visible in Inner.</div><div dir="auto" class=""><br class=""><blockquote type="cite" class=""><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Mar 28, 2016 at 7:30 AM Matthew Judge <<a href="mailto:matthew.judge@gmail.com" target="_blank" class="">matthew.judge@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 28, 2016 at 6:41 AM, Ilya Belenkiy <span dir="ltr" class=""><<a href="mailto:ilya.belenkiy@gmail.com" target="_blank" class="">ilya.belenkiy@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr" class="">lexical scope is the other way around: "inner" can see "outer". For example:<div class=""><br class=""></div><div class="">func f() {</div><div class=""> let outer = 0</div><div class=""> // f cannot use inner</div><div class=""> func g() {</div><div class=""> let inner = 1</div><div class=""> // g can use outer</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Maybe I'm off in my terminology, but I think my code example matches what you are saying here (outer is visible to g() but inner is not visible to f()</div></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr" class=""><div class=""></div><div class="">It would work the same way for the access level. That said, I'd rather not include this in the proposal. </div></div></blockquote><div class=""><br class=""></div></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">So as the proposal stands now, what is the scope that innerVar is visible to in the following code: Inner or Outer?</div><div class=""><br class=""></div><div class="">class Outer {</div><div class=""> class Inner {</div><div class=""> private var innerVar: Int</div></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> }</div><div class="">}</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr" class=""><div class="">The only change that the core team requested was the name changes. I personally would prefer a completely private version where you cannot inject a class into a scope to get access to the scope internals, but it's an edge case that could be argued either way, and I don't want to start another lengthy discussion. We already had quite a few.</div><div class=""><div class=""><div class=""><br class=""></div><div class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, Mar 27, 2016 at 11:17 PM Matthew Judge <<a href="mailto:matthew.judge@gmail.com" target="_blank" class="">matthew.judge@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="auto" class=""><div class=""></div><div class="">I know it was suggested that it be the subject of a different thread, but it might be good to clarify how the new private is going to work (or at least what is currently envisioned).</div><div class=""><br class=""></div><div class="">My understanding is that the new private would be: </div><div class="">- visible only to the immediately enclosing scope</div><div class="">- including the scope of a inner nested scope</div><div class="">- not including the scope of an outer nested scope</div><div class="">- not visible to an extension </div><div class=""><br class=""></div><div class="">Said in code (all in the same file):</div><div class="">----------</div><div class="">class Outer { // Outer visible to module</div><div class=""> private var a: Int // visible to Outer, Inner1, & Inner2</div><div class=""><br class=""></div><div class=""> class Inner1 { // Inner1 visible to module</div><div class=""> private var b: Int // visible to Inner1 only</div><div class=""> }</div><div class=""> private class Inner2 { // visible to Outer & Inner(s)</div><div class=""> var c: Int // visible to Outer & Inner(s)</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">extension Outer { // visible to module</div><div class=""> // 'a', 'b', and 'Inner2' NOT visible</div><div class="">}</div><div class="">----------</div><div class="">If this is the intended meaning of private, then fileprivate seems to be the same as private (private to the enclosing scope... which happens to be the file).</div><div class=""><br class=""></div><div class="">Something declared "private" at the top level of a file is fileprivate. There would still need to be a way to reference scopes other than the immediate one (especially since there is no way to say "private" and mean moduleprivate), though I think it would strengthen the argument for something along the lines of "private(file)", since it would even further reduce the cases where you are spelling something more than just "private"</div></div><div dir="auto" class=""><div class=""><br class=""></div><div class=""><br class="">On Mar 27, 2016, at 17:31, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><br class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On 27 Mar 2016, at 19:34, Jose Cheyo Jimenez via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">Public </div><div class="">External (default)</div><div class="">Internal</div><div class="">Private</div></div></div></blockquote><br class=""></div><div class="">I still feel like these are still too vague; I’m not sure I like the use of external, as public to me is external since it exports outside of the module, whereas what you’re proposing is in fact just limited to the module itself. I dislike the current internal keyword too, but at least it reads as “internal to this module", this is why the more specific terms are better like:</div></div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span style="white-space:pre-wrap" class=""> </span>public<span style="white-space:pre-wrap" class=""> </span>as-is, item is public/exported outside of module</font></div><div class=""><font face="Monaco" class=""><span style="white-space:pre-wrap" class=""> </span>private(module) or private<span style="white-space:pre-wrap" class=""> </span>current internal, item is private to this module, would be the default</font></div><div class=""><font face="Monaco" class=""><span style="white-space:pre-wrap" class=""> </span>private(file)<span style="white-space:pre-wrap" class=""> </span>current private, item is private to this file</font></div><div class=""><font face="Monaco" class=""><span style="white-space:pre-wrap" class=""> </span>private(scope)<span style="white-space:pre-wrap" class=""> </span>new visibility type, item is private to the current scope</font></div><div class=""><br class=""></div><div class="">Assuming I’m understanding the restriction properly this time =)</div><div class=""><br class=""></div><div class="">It’s also the easiest method if we do add another visibility later for sub-classes such as private(type), as it doesn’t even require a new keyword.</div></div></blockquote></div><div dir="auto" class=""><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span></div></blockquote></div><div dir="auto" class=""><blockquote type="cite" class=""><div class=""><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></blockquote></div></div></div></div></div>
</blockquote></div></div></div></blockquote></div>
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>