<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="">On Apr 3, 2017, at 11:34 AM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<div><blockquote type="cite" class=""><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="">Hello Swift Community,<div class=""><br class=""></div><div class="">In rejecting <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md" class="">SE-0159</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.</div><div class=""><br class=""></div><div class="">The design, specifically, is that a “private” member declared within a type “X” or an extension thereof would be accessible from:</div><div class=""><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* An extension of “X” in the same file</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* The definition of “X”, if it occurs in the same file</div><div 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</div></div></div></div></blockquote><div><br class=""></div><div>Another way to explain this is as a relaxation of the Swift 3 access control, to would allow private members in a type to also be accessible in extensions to that type, so long as they are in the same file.</div><div><br class=""></div><div>While I typically try to avoid chiming in on early discussions like this, I pretty strongly believe that this is a good solution for the reasons you mention:</div><div><br class=""></div><div> - fileprivate should really become much more rare, which makes it more meaningful and significant where it occurs. This was the original idea and intent behind SE-0025.</div><div><br class=""></div><div><div> - Similarly, this simplifies access control for most people. Most people will now only care about private/internal/public. fileprivate will become an expert feature used in specific cases to solve a specific class of problems. Progressive disclosure of complexity is important.</div><div><br class=""></div></div><div> - This design is true to the existing design of Swift: we want to encourage the implementation of types to be freely broken into extensions. This alignment with extension oriented programming was the one important virtue of the Swift 1/2 access control design that Swift 3 lost.</div><div><br class=""></div><div><br class=""></div><div>From a pragmatic perspective, I feel like this is a great solution that really does solve the problems we have with current access control, all without breaking source compatibility. This is also a major progression from where we are, and doesn’t appear to cut off any future directions (e.g. submodules) since those are cross-file concepts that live between internal/public or between fileprivate/internal.</div><div><br class=""></div><div>Just MHO, but I think that the rhetorical attempts to paint this as being similar to “protected” are unsound.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div></div></body></html>