<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 class=""><span style="font-family: 'Avenir Light'; -webkit-text-stroke-color: rgb(0, 0, 0); -webkit-text-stroke-width: initial;" class="">Dear Colleague Travellers In Turbulent And Interesting Digital Times :) </span></div><div class=""><div style="margin: 0px; line-height: normal; font-family: 'Avenir Light'; -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(0, 0, 0); min-height: 19px;" class=""><span style="font-kerning: none" class=""></span><br class=""></div><div style="margin: 0px; line-height: normal; font-family: 'Avenir Light'; -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(0, 0, 0);" class=""><span style="font-kerning: none" class="">Sorry, that I have not read all other opinions on this thread thoroughly,</span></div><div style="margin: 0px; line-height: normal; font-family: 'Avenir Light'; -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(0, 0, 0);" class=""><span style="font-kerning: none" class="">there's so much of it which confuses me. The sheer volume of this traffic gives me the impression that scope management is Swift is fundamentally wrong. </span></div><div style="margin: 0px; line-height: normal; font-family: 'Avenir Light'; -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(0, 0, 0); min-height: 19px;" class=""><span style="font-kerning: none" class=""></span><br class=""></div><div style="margin: 0px; line-height: normal; font-family: 'Avenir Light'; -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(0, 0, 0);" class=""><span style="font-kerning: none" class="">As written before on another thread, namely that currently all members of a class or struct are exposed by default, due to having a default scope of ‘internal’ and are therefore accessible in the entire module is imho very bad and unstructured programming practice. (e.g. why are the members of a function (correctly) have private scope and classes and struct don't have this? Isn't that very inconsistent? </span></div><div style="margin: 0px; line-height: normal; font-family: 'Avenir Light'; -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(0, 0, 0); min-height: 19px;" class=""><span style="font-kerning: none" class=""></span><br class=""></div><div style="margin: 0px; line-height: normal; font-family: 'Avenir Next'; color: rgb(51, 51, 51); -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(51, 51, 51); background-color: rgb(255, 255, 255);" class=""><span style="font-kerning: none" class="">In Swift there should be lexical scope only, I think, as in most procedural / OOP programming languages. This is a very simple and above all consistent rule, easy to understand for everyone, even rookies, and also would make programming in Swift more consistent and reliable. (Maybe it would even simplify the compiler processing more or less, but I have not enough knowledge about this.)</span></div><div style="margin: 0px; line-height: normal; font-family: 'Avenir Next'; color: rgb(51, 51, 51); -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(51, 51, 51); background-color: rgb(255, 255, 255); min-height: 19px;" class=""><span style="font-kerning: none" class=""></span><br class=""></div><div style="margin: 0px; line-height: normal; font-family: 'Avenir Next'; color: rgb(51, 51, 51); -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(51, 51, 51); background-color: rgb(255, 255, 255);" class=""><span style="font-kerning: none" class="">Having consistent lexical scope only, with no exceptions, would in almost all cases eliminate the necessity to explicitly use the keywords “private” and “fileprivate”. . . The latter imho is really awkward, solid proof of the inconsistency with current Swift scoping, because the scope of what's in a file is treated differently that that of other coding scopes, like class, struct, function or any other {} block... isn't it? </span></div><div style="margin: 0px; line-height: normal; font-family: 'Avenir Next'; color: rgb(51, 51, 51); -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(51, 51, 51); background-color: rgb(255, 255, 255); min-height: 19px;" class=""><span style="font-kerning: none" class=""></span><br class=""></div><div style="margin: 0px; line-height: normal; font-family: 'Avenir Next'; color: rgb(51, 51, 51); -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(51, 51, 51); background-color: rgb(255, 255, 255);" class=""><span style="font-kerning: none" class="">So I'd prefer consistent lexical scope only, that is, unless overruled by a scope modifier, an item should be available only within the code level/unit where it is declared.</span></div><div style="margin: 0px; line-height: normal; font-family: 'Avenir Next'; color: rgb(51, 51, 51); -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(51, 51, 51); background-color: rgb(255, 255, 255); min-height: 19px;" class=""><span style="font-kerning: none" class=""></span><br class=""></div><div style="margin: 0px; line-height: normal; font-family: 'Avenir Next'; color: rgb(51, 51, 51); -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(51, 51, 51); background-color: rgb(255, 255, 255);" class=""><span style="font-kerning: none" class="">However, I assume that it is too late to correct this, as it would turn the existing code base of all Swift users completely upside down, wouldn't it?</span></div><div style="margin: 0px; line-height: normal; font-family: 'Avenir Next'; color: rgb(51, 51, 51); -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(51, 51, 51); background-color: rgb(255, 255, 255);" class=""><span style="font-kerning: none" class="">making it necessary for the ones supporting this to flee to another universe to avoid repercussions... the very idea...</span></div><div style="margin: 0px; line-height: normal; font-family: 'Avenir Next'; color: rgb(51, 51, 51); -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(51, 51, 51); background-color: rgb(255, 255, 255); min-height: 19px;" class=""><span style="font-kerning: none" class=""></span><br class=""></div><div style="margin: 0px; line-height: normal; font-family: 'Avenir Next'; color: rgb(51, 51, 51); -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(51, 51, 51); background-color: rgb(255, 255, 255);" class=""><span style="font-kerning: none" class="">Kind Regards</span></div><div style="margin: 0px; line-height: normal; font-family: 'Avenir Next'; color: rgb(51, 51, 51); -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(51, 51, 51); background-color: rgb(255, 255, 255);" class=""><span style="font-kerning: none" class="">TedvG</span></div></div><div style="margin: 0px; line-height: normal; font-family: 'Avenir Next'; color: rgb(51, 51, 51); -webkit-text-stroke-width: initial; -webkit-text-stroke-color: rgb(51, 51, 51); background-color: rgb(255, 255, 255);" class=""><span style="font-kerning: none" class=""><a href="http://www.tedvg.com" class="">www.tedvg.com</a></span></div><div class=""><span style="font-kerning: none" class=""><br class=""></span></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><span style="font-family: Avenir-Medium;" class="">Date: Wed, 5 Apr 2017 20:34:27 -0500</span><br style="font-family: Avenir-Medium;" class=""><span style="font-family: Avenir-Medium;" class="">From: Matthew Johnson <</span><a href="mailto:matthew@anandabits.com" style="font-family: Avenir-Medium;" class="">matthew@anandabits.com</a><span style="font-family: Avenir-Medium;" class="">></span><br style="font-family: Avenir-Medium;" class=""><span style="font-family: Avenir-Medium;" class="">To: Colin Barrett <</span><a href="mailto:colin@springsandstruts.com" style="font-family: Avenir-Medium;" class="">colin@springsandstruts.com</a><span style="font-family: Avenir-Medium;" class="">></span><br style="font-family: Avenir-Medium;" class=""><span style="font-family: Avenir-Medium;" class="">Cc: swift-evolution <</span><a href="mailto:swift-evolution@swift.org" style="font-family: Avenir-Medium;" class="">swift-evolution@swift.org</a><span style="font-family: Avenir-Medium;" class="">></span><br style="font-family: Avenir-Medium;" class=""><span style="font-family: Avenir-Medium;" class="">Subject: Re: [swift-evolution] Type-based ‘private’ access within</span><br style="font-family: Avenir-Medium;" class=""><span class="Apple-tab-span" style="font-family: Avenir-Medium; white-space: pre;"> </span><span style="font-family: Avenir-Medium;" class="">a file</span><br style="font-family: Avenir-Medium;" class=""><span style="font-family: Avenir-Medium;" class="">Message-ID: <</span><a href="mailto:B31DEAB3-7826-49B8-A829-0454E1A573E1@anandabits.com" style="font-family: Avenir-Medium;" class="">B31DEAB3-7826-49B8-A829-0454E1A573E1@anandabits.com</a><span style="font-family: Avenir-Medium;" class="">></span><br style="font-family: Avenir-Medium;" class=""><span style="font-family: Avenir-Medium;" class="">Content-Type: text/plain; charset="utf-8"</span><br style="font-family: Avenir-Medium;" class=""><br style="font-family: Avenir-Medium;" class=""><br style="font-family: Avenir-Medium;" class=""><blockquote type="cite" style="font-family: Avenir-Medium;" class="">On Apr 5, 2017, at 7:11 PM, Colin Barrett via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">I'm broadly in favor of this.<br class=""><br class="">On Mon, Apr 3, 2017 at 2:35 PM Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>> wrote:<br class="">Hello Swift Community,<br class=""><br class="">In rejecting SE-0159 <<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md</a>>, the core team described a potential direction we would like to investigate for “private” access control that admits a limited form of type-based access control within files. The core team is seeking some discussion here and a motivated volunteer to put together a proposal along these lines for review in the Swift 4 time-frame (i.e., very soon). To be clear, the core team it’s sure this is the right direction to go… but it appears promising and we would *love* to be able to settle the access-control issue.<br class=""><br class="">The design, specifically, is that a “private” member declared within a type “X” or an extension thereof would be accessible from:<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* An extension of “X” in the same file<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* The definition of “X”, if it occurs in the same file<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* A nested type (or extension thereof) of one of the above that occurs in the same file<br class=""><br class="">This design has a number of apparent benefits:<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>+ “private” becomes the right default for “less than whole module” visibility, and aligns well with Swift coding style that divides a type’s definition into a number of extensions.<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>+ “fileprivate” remains for existing use cases, but now it’s use it more rare, which has several advantages:<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>+ It fits well with the "progressive disclosure” philosophy behind Swift: you can use public/internal/private for a while before encountering and having to learn about “fileprivate” (note: we thought this was going to be true of SE-0025 <<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md</a>>, but we were clearly wrong)<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>+ When “fileprivate” occurs, it means there’s some interesting coupling between different types in the same file. That makes fileprivate a useful alert to the reader rather than, potentially, something that we routinely use and overlook so that we can separate implementations into extensions.<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>+ “private” is more closely aligned with other programming languages that use type-based access control, which can help programmers just coming to Swift. When they reach for “private”, they’re likely to get something similar to what they expect—with a little Swift twist due to Swift’s heavy use of extensions.<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>+ Loosening the access restrictions on “private” is unlikely to break existing code.<br class=""><br class="">There are likely some drawbacks:<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- Developers using patterns that depend on the existing lexically-scoped access control of “private” may find this new interpretation of “private” to be insufficiently strict<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- Swift’s access control would go from “entirely lexical” to “partly lexical and partly type-based”, which can be viewed as being more complicated<br class=""><br class="">I think it might not as complicated as it may first appear. I haven't fully convinced myself of this, but I believe that it would be lexically scoped modulo inlining extensions.<br class=""><br class="">To put it somewhat more formally (and awkwardly), if one imagines a textual transformation which blindly inlines any extension in a single file into their type definitions (should those definitions occur within that file) then accessing a "private" member in the original file would compile if and only if the access would be lexically scoped if the above postulated transformation were to be applied to it.<br class=""><br class="">This is a pleasing property (to me anyway) as it means that it is unlikely (impossible?) for moving code from one extension (or definition) to another to cause a compilation failure.<br class=""><br class="">Take this with a grain of salt of course, as there's probably an edge case I'm not thinking of :P (This is why we write proofs!)<br class=""></blockquote><br style="font-family: Avenir-Medium;" class=""><span style="font-family: Avenir-Medium;" class="">This is a very interesting perspective Colin. This idea seems to align well with the intent for extensions that Chris stated earlier. This way of thinking about it does make the proposal much cleaner conceptually. If we’re going to adopt this perspective I think we should go all the way - same file extensions really should be inline semantically. This means same file extensions would also have the ability to include stored properties which is something many people have asked for. </span><br style="font-family: Avenir-Medium;" class=""><br style="font-family: Avenir-Medium;" class=""><span style="font-family: Avenir-Medium;" class="">I wonder how David and the core team would feel about modifying the proposal to adopt this “inline same file extensions" perspective. IMO this motivates the proposal better by acknowledging that most developers in the community use same file extensions for purely organization purposes. The implicit desire is that they be transparent boundaries that carry no semantic weight at all. I think a proposal with this kind of motivation is more likely to be well received by the broader community than a change that is only focused on access control in a very specific context. Instead of “why do they keep changing access control” the response might be “yay, extensions finally work the way I always wanted them to”.</span><br style="font-family: Avenir-Medium;" class=""><br style="font-family: Avenir-Medium;" class=""><span style="font-family: Avenir-Medium;" class="">Cheers,</span><br style="font-family: Avenir-Medium;" class=""><span style="font-family: Avenir-Medium;" class="">Matthew</span><br style="font-family: Avenir-Medium;" class=""><br style="font-family: Avenir-Medium;" class=""><blockquote type="cite" style="font-family: Avenir-Medium;" class=""><br class="">Cheers,<br class="">-Colin<br class=""><br class="">Thoughts? Volunteer?<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- Doug<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote></blockquote><div class=""><br class=""></div></body></html>