<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 Mar 23, 2017, at 2:37 PM, Charles Srstka <<a href="mailto:cocoadev@charlessoft.com" class="">cocoadev@charlessoft.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class="">On Mar 23, 2017, at 2:15 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:<br class=""></blockquote><div class=""><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div 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="">What I’m suggesting is that we could accomplish the same functionality by enhancing extensions. You can make a case that using a different keyword for same-module extensions that are allowed to have stored properties is a good idea. I’m not sure I would support that though.</div></div></blockquote><div class=""><br class=""></div><div class="">The problem is that people are using extensions to implement part of the original class definition. Part of what is making that pattern awkward is that private members are not accessible from the extensions. Given the SE-0159 discussion, it appears that there is a non-negligible threat of losing the very ability to have scoped members at all if we don’t think of a better alternate solution.</div><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class="" 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-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">2) I’m not proposing changing the meaning of ‘private’ here. Since partial implementations would all glom into one lexical scope, all the current access control rules would apply as they currently do. This is simply a way to write a class or struct declaration in multiple parts, without having to use extensions.</div></div></div></blockquote><div 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=""><br class=""></div><div 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="">This does not fit with any definition of “lexical scope” I am familiar with. I wouldn’t want to see Swift adopt this definition of lexical scope.</div></div></blockquote></div><br class=""><div class="">No definitions required. All I’m proposing is basically preprocessing the thing into one type declaration.</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">class Foo {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func bar() {}</div><div class="">}</div><div class=""><br class=""></div><div class="">partial Foo {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func baz() {}</div><div class="">}</div><div class=""><br class=""></div><div class="">just becomes syntactic sugar for:</div><div class=""><br class=""></div><div class="">class Foo {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func bar() {}</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func baz() {}</div><div class="">}</div><div class=""><br class=""></div><div class="">After this conversion, bar and baz are in the same lexical scope. No new definitions of anything are required.</div></div></div></blockquote><div><br class=""></div><div>Sure, but this does effectively violate lexical scope boundaries as they exist in the original source.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">You can also think of the “Foo_Private.h” headers that can be shared amongst several different files in Objective-C.</div><div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></body></html>