<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Mar 26, 2017, at 10:43 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>This reaches the crux of the issue, doesn't it? The Swift 2 design for access modifiers does exactly what you reject: that design is based on the premise that it is wise for file organization to follow encapsulation.<br></div></blockquote><div><br></div><div>It's always a gamble speculating about the premise of someone else's design. That said, if I had to guess I would imagine maybe it had as much to do with the legacy of C-family languages and header files as anything else.</div><br><blockquote type="cite"><div><br>Now, afaik, the accepted rationale for "new private" was that there needed to be something _more_ to fill out that scheme. And here the argument is that it didn't really add much benefit but brought about more complexity.<br><br>If, however, what you're saying is that you reject the whole idea behind "fileprivate" altogether, well...I don't know if making it possible to ignore file-based encapsulation was ever really on the menu.</div></blockquote><div><br></div><div>I'm not saying I reject the idea of file scopes at all. <span style="background-color: rgba(255, 255, 255, 0);">There are submodule designs that would make file scopes redundant, but that is as far as I've gone. We certainly need it in Swift 4 where we won't have submodules at all. </span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">However, if the community strongly desires a change to remove one of the access modifiers I do think we should explore submodule designs that would fill the use cases for file scope and perhaps allow us to eliminate that. This would obviously need to happen in a future release where that is in scope. That is why I've been arguing that we should not force churn on users now. We should wait until we are ready to address all problems related to access control and submodules more holistically.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">It sounds like the comments in my reply to John may not have even clear to you. What I'm saying is that file scopes and submodules cannot replace scoped access without forcing a tradeoff between code organization and encapsulation. </span><span style="background-color: rgba(255, 255, 255, 0);">This is a tradeoff I don't want to be forced to make. If I choose encapsulation that would result in many more very small files (10s of lines) than I would like. Just as large files can make code difficult to navigate, too many very small files can also make code difficult to navigate and can result in a lot of thrashing between files. </span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">It should be possible to place small types together in the same file without sacrificing encapsulation. It should also be possible to have a small helper type in the same file as the type it is supporting without sacrificing encapsulation. This requirement can only be met by scoped access or something very similar.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">In fact, I very often use file scopes in conjunction with scopes access. `private` is used to encapsulate state which is crucial to preserving invariants, etc of a helper type and `fileprivate` is used to restrict visibility of the helper type to the current file.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><br><blockquote type="cite"><div><div class="gmail_quote"><div dir="ltr">On Sun, Mar 26, 2017 at 07:30 Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">Sent from my iPad</div></div><div dir="auto" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">On Mar 26, 2017, at 4:13 AM, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Mar 26, 2017, at 4:27 AM, Goffredo Marocchi <<a href="mailto:panajev@gmail.com" class="gmail_msg" target="_blank">panajev@gmail.com</a>> wrote:</div><div class="gmail_msg"><div dir="auto" class="gmail_msg"><div class="gmail_msg">On 26 Mar 2017, at 06:54, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><div class="gmail_msg"><div class="gmail_msg"><p class="gmail_msg"><font size="2" class="gmail_msg">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="gmail_msg"></p></div></div></blockquote><div class="gmail_msg">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="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div></div><div dir="auto" class="gmail_msg"><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> 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><div dir="auto" class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">John.</div><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="auto" class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">John.</div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="gmail_msg"><font size="2" class="gmail_msg">-Carl</font><br class="gmail_msg"><br class="gmail_msg"><span id="m_7736999603649871517cid:1__=8FBB0A7DDFB206B68f9e8a93df938690918c8FB@" class="gmail_msg"><graycol.gif></span><font size="2" color="#424282" class="gmail_msg">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="gmail_msg"><br class="gmail_msg"><font size="2" color="#5F5F5F" class="gmail_msg">From: </font><font size="2" class="gmail_msg">Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>></font><br class="gmail_msg"><font size="2" color="#5F5F5F" class="gmail_msg">To: </font><font size="2" class="gmail_msg">Carl Brown1/US/IBM@IBM</font><br class="gmail_msg"><font size="2" color="#5F5F5F" class="gmail_msg">Cc: </font><font size="2" class="gmail_msg">Drew Crawford <<a href="mailto:drew@sealedabstract.com" class="gmail_msg" target="_blank">drew@sealedabstract.com</a>>, Jonathan Hull <<a href="mailto:jhull@gbis.com" class="gmail_msg" target="_blank">jhull@gbis.com</a>>, swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>></font><br class="gmail_msg"><font size="2" color="#5F5F5F" class="gmail_msg">Date: </font><font size="2" class="gmail_msg">03/25/2017 12:33 AM</font><br class="gmail_msg"><font size="2" color="#5F5F5F" class="gmail_msg">Subject: </font><font size="2" class="gmail_msg">Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels</font><br class="gmail_msg"></p><hr width="100%" size="2" align="left" noshade="" style="color:#8091a5" class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">Would it change your opinion on the proposal?<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <<a href="mailto:Carl.Brown1@ibm.com" class="gmail_msg" target="_blank"><u class="gmail_msg"><font color="#0000FF" class="gmail_msg">Carl.Brown1@ibm.com</font></u></a>> wrote:
<ul class="gmail_msg"><font size="2" class="gmail_msg">I would very much like to see your proof that the resultant code is unchanged in an arbitrary codebase. </font><br class="gmail_msg"><font size="2" class="gmail_msg"><br class="gmail_msg">-Carl</font><br class="gmail_msg"><br class="gmail_msg"><span id="m_7736999603649871517cid:1__=8FBB0A7DDFB206B68f9e8a93df938690918c8FB@" class="gmail_msg"><graycol.gif></span><font size="2" color="#424282" class="gmail_msg">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" class="gmail_msg" target="_blank"><u class="gmail_msg"><font size="2" color="#0000FF" class="gmail_msg">Carl.Brown1@ibm.com</font></u></a><font size="2" color="#424282" class="gmail_msg">> wrote: > Maybe this is the core</font><br class="gmail_msg"><font size="2" color="#5F5F5F" class="gmail_msg"><br class="gmail_msg">From: </font><font size="2" class="gmail_msg">Xiaodi Wu <</font><a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank"><u class="gmail_msg"><font size="2" color="#0000FF" class="gmail_msg">xiaodi.wu@gmail.com</font></u></a><font size="2" class="gmail_msg">></font><font size="2" color="#5F5F5F" class="gmail_msg"><br class="gmail_msg">To: </font><font size="2" class="gmail_msg">Carl Brown1/US/IBM@IBM</font><font size="2" color="#5F5F5F" class="gmail_msg"><br class="gmail_msg">Cc: </font><font size="2" class="gmail_msg">Drew Crawford <</font><a href="mailto:drew@sealedabstract.com" class="gmail_msg" target="_blank"><u class="gmail_msg"><font size="2" color="#0000FF" class="gmail_msg">drew@sealedabstract.com</font></u></a><font size="2" class="gmail_msg">>, Jonathan Hull <</font><a href="mailto:jhull@gbis.com" class="gmail_msg" target="_blank"><u class="gmail_msg"><font size="2" color="#0000FF" class="gmail_msg">jhull@gbis.com</font></u></a><font size="2" class="gmail_msg">>, swift-evolution <</font><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank"><u class="gmail_msg"><font size="2" color="#0000FF" class="gmail_msg">swift-evolution@swift.org</font></u></a><font size="2" class="gmail_msg">></font><font size="2" color="#5F5F5F" class="gmail_msg"><br class="gmail_msg">Date: </font><font size="2" class="gmail_msg">03/25/2017 12:01 AM</font><font size="2" color="#5F5F5F" class="gmail_msg"><br class="gmail_msg">Subject: </font><font size="2" class="gmail_msg">Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels</font><br class="gmail_msg"><hr width="100%" size="2" align="left" noshade="" class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <<a href="mailto:Carl.Brown1@ibm.com" class="gmail_msg" target="_blank"><u class="gmail_msg"><font color="#0000FF" class="gmail_msg">Carl.Brown1@ibm.com</font></u></a>> wrote:
<p class="gmail_msg">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="gmail_msg"><br class="m_7736999603649871517webkit-block-placeholder gmail_msg"></div></ul><br class="gmail_msg"><div class="gmail_msg"><br class="m_7736999603649871517webkit-block-placeholder gmail_msg"></div><p class="gmail_msg"><br class="gmail_msg">
</p></div>
_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div><br class="gmail_msg"></div></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg">_______________________________________________</span><br class="gmail_msg"><span class="gmail_msg">swift-evolution mailing list</span><br class="gmail_msg"><span class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a></span><br class="gmail_msg"><span class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class="gmail_msg"></div></blockquote></div></div></blockquote></div><br class="gmail_msg"></div></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg">_______________________________________________</span><br class="gmail_msg"><span class="gmail_msg">swift-evolution mailing list</span><br class="gmail_msg"><span class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a></span><br class="gmail_msg"><span class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class="gmail_msg"></div></blockquote></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>
</div></blockquote></body></html>