<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On 4 Apr 2017, at 17:26, Shawn Erickson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div><br><div class="gmail_quote"><div>On Mon, Apr 3, 2017 at 8:38 PM Adam Knight via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg">On Apr 3, 2017, at 8:11 PM, Nevin Brackett-Rozinsky via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="gmail_msg">My remaining hope is that Swift will acquire a submodule design which renders “fileprivate” essentially redundant. If we get an access level that means “visible in a group of tightly-related files” and it has a concise spelling, then I will use that just about exclusively.</span></div></blockquote></div><br class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">You mean a namespace?&nbsp; Ask some greybeard C++ developers how that one worked out.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Honestly, regardless of names, I see the following needs:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">1. Keep your mitts off this code, this is for me alone. You will break things if you change this.</div><div class="gmail_msg">2. This one is for me and my relatives who know what we're doing with it.</div><div class="gmail_msg">3. This is for my group as we work together on this problem.</div><div class="gmail_msg">4. This is for anyone that wants us to solve this problem for them.</div><div class="gmail_msg">5. This is for anyone that wants to try to solve this problem some other way.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">(private, protected, internal, public, open — perhaps?)</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">What we call them matters little, as long as none of those names are fileprivate. 🙂 &nbsp;File-based access control is so very ‘70s (and this is coming from someone who has used C for a Very Long Time and loves it more than Swift, honestly). For *this* language, it’s the wrong tool.&nbsp; We have those new-fangled hierarchical types and extensions all in those fancy little modules, so let’s use them as the people expect them to be used.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">When submodules are A Thing, revisit them in terms of the “definitions" above and see where things fit.&nbsp; If we — heaven forbid — think we need an additional “export” keyword then we’ll have that firefight</div></div></div></blockquote><div><br></div><div>Yeah basically my main objection to this proposed change and my general dislike with current access controls is that they continue to depend on file level scoping to provide for a functionality like "protected" in C++ (not that I exactly want that either, at least not friend). This forces you to organize things in certain ways if you want to do anything more then internal module level access.</div></div></div></div></blockquote><div><br></div><div><span style="background-color: rgba(255, 255, 255, 0);">Even if you don't like it, Swift's access control's reliance on file scoping is here to stay. It's too late to change that.</span></div><br><blockquote type="cite"><div><div><div class="gmail_quote"><div>I don't like the proposal primarily because it conflates file scope and private scope which I think makes things more confusing and builds more on the "crutch" of a file construct for access control. I much rather keep things clear and explicit by requiring the use of fileprivate for those situations instead of muddling up private (at least for now).</div></div></div></div></blockquote><div><br></div><div>It's true that it conflates lexical and file scope. That's it's one drawback.</div><br><blockquote type="cite"><div><div><div class="gmail_quote"><div>Instead I would want a protected like thing to be looked at that would replace the need for fileprivate and that should be looked at in conjunction with sub modules and likely properties, etc. ...let's spend out energy on breaking away from file based access control. (that would make playground better as well)</div></div></div></div></blockquote><div><br></div><div>Whatever we want, the core team has made it clear that access levels won't be changing as substantially as that from now on. That's the entire reason 0159 was rejected: to not break source compatibility with users of private &amp; fileprivate. So how can we expect any major change in the future?</div><div><br></div><div>That's why the current type-based proposal is the only viable alternative we have to resolve the grievances 0159 brought forward now. There's no "later".</div><br><blockquote type="cite"><div><div><div class="gmail_quote"><div>I feel most of the access controls levels in swift are well setup for progressive disclosure... internal by default it great, you can get to work without needing to know access controls. You can start to learn it by putting your code in modules and dealing with public (and sometimes open) which is great first way to understand the what and why of wanting to control access to things. You can then start to learn about inter-module encapsulation using private and then fileprivate.</div><div><br></div><div>-Shawn</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"></div></div></div></blockquote><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"></div></div></div>
</blockquote></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>