<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 26, 2017, at 12:26 PM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.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=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 26, 2017, at 8:30 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><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="">On Mar 26, 2017, at 4:13 AM, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" 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;" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 26, 2017, at 4:27 AM, Goffredo Marocchi <<a href="mailto:panajev@gmail.com" class="">panajev@gmail.com</a>> wrote:</div><div class=""><div dir="auto" class=""><div class="">On 26 Mar 2017, at 06:54, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div class=""><p class=""><font size="2" class="">Yes, it would change my opinion of it. I wouldn't become a strong supporter because I don't see any value in it, but a rigorous proof that this proposal could not possibly introduce regressions to any existing codebases would change my opinion from "strongly against" to "doesn't matter to me, I'll stop arguing against it and go get my real work done".</font><br class=""></p></div></div></blockquote><div class="">Speaking just for myself, this was a key part of why I was attracted to this proposal: it seemed to me to be extremely unlikely to cause regressions in behavior. Even without any special behavior in the migrator, code will mostly work exactly as before: things that would have been invalid before will become valid, but not the other way around. The exception is that old-private declarations from scopes in the same file can now be found by lookups in different scopes (but still only within the same file). It should be quite straightforward for the migrator to detect when this has happened and report it as something for the programmer to look at. The proposal causes a small regression in functionality, in that there's no longer any way to protect scopes from accesses within the file, but (1) it's okay for Swift to be opinionated about file size and (2) it seems to me that a workable sub-module proposal should solve that more elegantly while simultaneously addressing the concerns of the people who dislike acknowledging the existence of files.</div></div></div></blockquote><div class=""><br class=""></div><div class="">The opinionated flag sometimes, like being Swifty, is being used to swath away disagreement, but opinions should be reasonable and pragmatic too... opinionated as "you will code this way and you will like it" seems hardly ideal too if abused constantly. Programming is a creative endeavour too.</div><div class=""><br class=""></div><div class="">Also, removing a feature that is used and is useful because "maybe" a year or more away there could be a feature that may address the concerns of the people we are stripping away the current feature from seems quite harsh and unfriendly at best... not very logical either.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Scoped-private is not some awesomely expressive feature. It's an access restriction. The "opinion" I'm talking about hardly prevents you from coding however you like. It's just this: organizing your code into smaller, more self-contained components separated by file is good practice anyway, and when you do that, Swift will let you enforce that each component is properly encapsulated.</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 address the case where we have a small helper type that is only 10s of lines long, is not visible outside the file, and encapsulates an important part of the implementation using scoped private. The whole file is usually only a couple hundred lines. This is not an excessively long file and already contains a single component that is presented to the rest of the program.</div></div></blockquote><div class=""><br class=""></div>I acknowledge that this case exists, but by definition, it's a tiny amount of code being "protected" from an almost equally tiny amount of code.</div></div></div></blockquote><div><br class=""></div><div>Sure, but I’ve seen cases where it can be used to avoid problems that arise in real projects with experienced programmers. Compiler verification provides a useful “reminder” to both maintainers and reviewers about the correct thing to do. This can be especially helpful when somebody is new to a project or when revisiting code you haven’t looked at in quite some time.</div><div><br class=""></div><div>I would never argue that this is as important as many other features in Swift but that isn’t the standard that has been set. The standard that has been set for breaking changes is one of “actively harmful”. As I have stated before, I think one can make a reasonable case that the current names `fileprivate` and `private` are actively harmful. However, I don’t think a strong case can be made that scoped access in itself is actively harmful. Instead, I think a reasonably strong case has been made that it is actively harmful to remove it. If that were not the case we wouldn’t see roughly half of the responses to this thread saying no to this proposal. People are benefiting from this feature.</div><br class=""><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="">Access control is primarily communicative. A person who adds unwanted uses of a private property can also just as easily change the access restriction. The point of private access control is to communicate that you've thought about it and that people should think before assuming that it's okay to use something. When you're talking about about tiny amounts of code, that level of communication really is good enough. </div></div></div></blockquote><div><br class=""></div><div>I largely agree. But I think the value in having the compiler catch accidental misuse is greater than most of the supporters of this proposal are acknowledging. The value is nowhere near the value of using Optional to model null, but scoped access control is able to catch bugs statically that would otherwise slip through to runtime. Most importantly, it can help catch “bugs" that might behave correctly today but will not behave correctly after a future change to the invariants preserved by the methods the rest of the file is supposed to be using.</div><br class=""><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="">It has to be, because access control is never going to be sufficiently expressive to express constraints like "this method can only be called from this other method" — we actively would not want to encourage programmers to engage in that level of pedantry, because some of them will, and they'll make themselves miserable and accomplish nothing of value, and they'll blame Swift (correctly) for implying that it was important.</div></div></div></blockquote><div><br class=""></div><div>I acknowledge that there is a degree of pedantry that becomes unhelpful. I don’t think scoped access crosses the line. Clearly others do. </div><div><br class=""></div><div>I greatly value the ability to state intent directly in the language and have that intent be verified by the compiler, particularly in areas where that verification can be leveraged to statically prevent bugs. There are a nontrivial amount of use cases where scoped access is able to do that very well and any other solution is going to end up feeling clunky at best or be impossible at worst.</div><br class=""><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=""><blockquote type="cite" class=""><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="">Some designs of submodules might allow us to properly encapsulate everything but if that requires us to put a small helper type in a separate file that would be a very unfortunate and inflexible constraint on how we are able to organize our code. </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=""><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=""> I don't want encapsulation concerns dictating how I physically organize my code. That is significant and unnecessary complexity if you ask me. It forces a tradeoff between desired physical organization and desired encapsulation. We should not force users to make this tradeoff.</div></div></blockquote><div class=""><br class=""></div>See, you say this, and you're apparently talking talking about the burdens of maintaining a 200-line file. </div></div></div></blockquote><div><br class=""></div><div>In ideal cases yes. Sometimes files grow to be 400-500 lines. Scoped access can reduce the amount of code to which protected state is visible by 90-95% or more in files (even in the 200 line range). This is an important benefit IMO.</div><br class=""><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="">Someone else says it, and their files are 10,000 lines long. </div></div></div></blockquote><div><br class=""></div><div>I don’t think we should remove a feature from the language just because some people abuse it. I’m sure we can find good examples of most features in Swift being abused.</div><br class=""><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="">I'm going to be opinionated and say that, no, physical organization is inherently linked to encapsulation because of the implicit outer scope of the file, and that if you care about encapsulation, you should also be organizing your code to minimize that outer scope, which will also make it trivial to understand how a private declaration is used and recognize in code reviews for changes that touch that file that they're accessing something they shouldn’t.</div></div></div></blockquote><div><br class=""></div>I don’t think touching a separate file makes is substantially easier to recognize in code reviews than a modified access level.</div><div><br class=""></div><div>There are many factors involved in deciding which file a piece of code goes in. If I have 300 lines of code that are all tightly related they should be in the same file to facilitate ease of reading and editing that code. Physical proximity matters not for logical reasons, but for pragmatic reasons. Maybe someday our tools will have features that make it easier to work with code that spans several files but alas we’re not there yet. This means that encapsulation <i class="">should not</i> be the only consideration. Pragmatism demands we consider human factors as well.<br class=""><div><br class=""></div><div>The implicit outer scope at the file boundary is one that only exists because it was introduced in Swift 2. It has precedent in the implementation related history of translation units and header files but that does not necessarily mean it is the best solution for Swift. Interestingly, if future tools succeed in making file boundaries matter less than they do today this implicit boundary would start to seem pretty strange and logical scopes would take on increased importance. This isn’t an argument against keeping file scopes - they are pragmatically important right now for a number of reasons - but it is an argument against removing the tool we have for referring to the current lexical scope.</div><div><br class=""></div><div>There is significant demand for submodules specifically because people want to be able to have smaller files without exposing things to the whole module. Again we see the language forcing a tradeoff between physical code organization and logical bounding of access to a member. I would be very surprised if scoped access bears more responsibility for large Swift files than the choice of files as the largest scope addressable by access control that is smaller than the module itself. If you want to encourage people to have smaller files this is the place to start.</div><div><br class=""></div><div>I don’t think tradeoffs between encapsulation and physical organization should be ignored. As noted in the previous paragraph, coupling them is partly responsible for the large file problem we have. I think the tradeoffs and the problems arising from them should be carefully considered. If they are not, they will continue popping up and people will continue asking for changes to the language. The best way to do this (IMO) is to defer the entire topic of access control until we can step back and revisit it holistically. </div><div><br class=""></div><div>Ultimately, many programmers want both tight encapsulation and the ability to physically organize their code in a way that is both logical and pragmatic. Is this too much to ask from the language (as a long-term goal)? I hope not.</div><div><br class=""></div><div><br class=""></div><br class=""><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="">John.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><br 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=""><blockquote type="cite" 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;" class=""><div class=""><div class=""><br class=""></div><div class="">John.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">John.</div><blockquote type="cite" class=""><div class=""><div class=""><p class=""><font size="2" class="">-Carl</font><br class=""><br class=""><span id="cid:1__=8FBB0A7DDFB206B68f9e8a93df938690918c8FB@" class=""><graycol.gif></span><font size="2" color="#424282" class="">Xiaodi Wu ---03/25/2017 12:33:55 AM---Would it change your opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <Carl.Br</font><br class=""><br class=""><font size="2" color="#5F5F5F" class="">From:<span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span></font><font size="2" class="">Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>></font><br class=""><font size="2" color="#5F5F5F" class="">To:<span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span></font><font size="2" class="">Carl Brown1/US/IBM@IBM</font><br class=""><font size="2" color="#5F5F5F" class="">Cc:<span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span></font><font size="2" class="">Drew Crawford <<a href="mailto:drew@sealedabstract.com" class="">drew@sealedabstract.com</a>>, Jonathan Hull <<a href="mailto:jhull@gbis.com" class="">jhull@gbis.com</a>>, swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>></font><br class=""><font size="2" color="#5F5F5F" class="">Date:<span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span></font><font size="2" class="">03/25/2017 12:33 AM</font><br class=""><font size="2" color="#5F5F5F" class="">Subject:<span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span></font><font size="2" class="">Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels</font><br class=""></p><hr width="100%" size="2" align="left" noshade="" class="" style="color: rgb(128, 145, 165);"><br class=""><br class=""><br class="">Would it change your opinion on the proposal?<br class=""><br class=""><br class="">On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <<a href="mailto:Carl.Brown1@ibm.com" target="_blank" class=""><u class=""><font color="#0000FF" class="">Carl.Brown1@ibm.com</font></u></a>> wrote:<ul class=""><font size="2" class="">I would very much like to see your proof that the resultant code is unchanged in an arbitrary codebase.<span class="Apple-converted-space"> </span></font><br class=""><font size="2" class=""><br class="">-Carl</font><br class=""><br class=""><span id="cid:1__=8FBB0A7DDFB206B68f9e8a93df938690918c8FB@" class=""><graycol.gif></span><font size="2" color="#424282" class="">Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <</font><a href="mailto:Carl.Brown1@ibm.com" target="_blank" class=""><u class=""><font size="2" color="#0000FF" class="">Carl.Brown1@ibm.com</font></u></a><font size="2" color="#424282" class="">> wrote: > Maybe this is the core</font><br class=""><font size="2" color="#5F5F5F" class=""><br class="">From:<span class="Apple-converted-space"> </span></font><font size="2" class="">Xiaodi Wu <</font><a href="mailto:xiaodi.wu@gmail.com" target="_blank" class=""><u class=""><font size="2" color="#0000FF" class="">xiaodi.wu@gmail.com</font></u></a><font size="2" class="">></font><font size="2" color="#5F5F5F" class=""><br class="">To:<span class="Apple-converted-space"> </span></font><font size="2" class="">Carl Brown1/US/IBM@IBM</font><font size="2" color="#5F5F5F" class=""><br class="">Cc:<span class="Apple-converted-space"> </span></font><font size="2" class="">Drew Crawford <</font><a href="mailto:drew@sealedabstract.com" target="_blank" class=""><u class=""><font size="2" color="#0000FF" class="">drew@sealedabstract.com</font></u></a><font size="2" class="">>, Jonathan Hull <</font><a href="mailto:jhull@gbis.com" target="_blank" class=""><u class=""><font size="2" color="#0000FF" class="">jhull@gbis.com</font></u></a><font size="2" class="">>, swift-evolution <</font><a href="mailto:swift-evolution@swift.org" target="_blank" class=""><u class=""><font size="2" color="#0000FF" class="">swift-evolution@swift.org</font></u></a><font size="2" class="">></font><font size="2" color="#5F5F5F" class=""><br class="">Date:<span class="Apple-converted-space"> </span></font><font size="2" class="">03/25/2017 12:01 AM</font><font size="2" color="#5F5F5F" class=""><br class="">Subject:<span class="Apple-converted-space"> </span></font><font size="2" class="">Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels</font><br class=""><hr width="100%" size="2" align="left" noshade="" class=""><br class=""><br class=""><br class="">On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <<a href="mailto:Carl.Brown1@ibm.com" target="_blank" class=""><u class=""><font color="#0000FF" class="">Carl.Brown1@ibm.com</font></u></a>> wrote:<span class="Apple-converted-space"> </span><p class="">My point is that, in rolling back the specific portion of SE-0025, case-sensitive find-and-replace will be the trickiest thing in most codebases, save those that result in invalid redeclarations. The behavior of the resultant code is, unless I'm mistaken, provably unchanged.</p><div class=""><br class="webkit-block-placeholder"></div></ul><br class=""><div class=""><br class="webkit-block-placeholder"></div><p class=""><br class=""></p></div>_______________________________________________<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=""></div></blockquote></div><br class=""></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" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite" 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;" 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" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span></div></blockquote></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></body></html>