<div><br><div class="gmail_quote"><div>On Wed, Apr 5, 2017 at 4:31 AM Vladimir.S 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">On 05.04.2017 7:02, Chris Lattner via swift-evolution wrote:<br class="gmail_msg">
> On Apr 3, 2017, at 11:34 AM, Douglas Gregor via swift-evolution<br class="gmail_msg">
> <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>>> wrote:<br class="gmail_msg">
>> Hello Swift Community,<br class="gmail_msg">
>><br class="gmail_msg">
>> In rejecting SE-0159<br class="gmail_msg">
>> <<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md</a>>,<br class="gmail_msg">
>> the core team described a potential direction we would like to<br class="gmail_msg">
>> investigate for “private” access control that admits a limited form of<br class="gmail_msg">
>> type-based access control within files. The core team is seeking some<br class="gmail_msg">
>> discussion here and a motivated volunteer to put together a proposal<br class="gmail_msg">
>> along these lines for review in the Swift 4 time-frame (i.e., very soon).<br class="gmail_msg">
>> To be clear, the core team it’s sure this is the right direction to go…<br class="gmail_msg">
>> but it appears promising and we would *love* to be able to settle the<br class="gmail_msg">
>> access-control issue.<br class="gmail_msg">
>><br class="gmail_msg">
>> The design, specifically, is that a “private” member declared within a<br class="gmail_msg">
>> type “X” or an extension thereof would be accessible from:<br class="gmail_msg">
>><br class="gmail_msg">
>> * An extension of “X” in the same file<br class="gmail_msg">
>> * The definition of “X”, if it occurs in the same file<br class="gmail_msg">
>> * A nested type (or extension thereof) of one of the above that occurs in<br class="gmail_msg">
>> the same file<br class="gmail_msg">
><br class="gmail_msg">
> Another way to explain this is as a relaxation of the Swift 3 access<br class="gmail_msg">
> control, to would allow private members in a type to also be accessible in<br class="gmail_msg">
> extensions to that type, so long as they are in the same file.<br class="gmail_msg">
><br class="gmail_msg">
> While I typically try to avoid chiming in on early discussions like this, I<br class="gmail_msg">
> pretty strongly believe that this is a good solution for the reasons you<br class="gmail_msg">
> mention:<br class="gmail_msg">
><br class="gmail_msg">
> - fileprivate should really become much more rare, which makes it more<br class="gmail_msg">
> meaningful and significant where it occurs. This was the original idea and<br class="gmail_msg">
> intent behind SE-0025.<br class="gmail_msg">
><br class="gmail_msg">
> - Similarly, this simplifies access control for most people. Most people<br class="gmail_msg">
> will now only care about private/internal/public. fileprivate will become<br class="gmail_msg">
> an expert feature used in specific cases to solve a specific class of<br class="gmail_msg">
> problems. Progressive disclosure of complexity is important.<br class="gmail_msg">
><br class="gmail_msg">
> - This design is true to the existing design of Swift: we want to<br class="gmail_msg">
> encourage the implementation of types to be freely broken into extensions.<br class="gmail_msg">
> This alignment with extension oriented programming was the one important<br class="gmail_msg">
> virtue of the Swift 1/2 access control design that Swift 3 lost.<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> From a pragmatic perspective, I feel like this is a great solution that<br class="gmail_msg">
> really does solve the problems we have with current access control, all<br class="gmail_msg">
> without breaking source compatibility. This is also a major progression<br class="gmail_msg">
> from where we are, and doesn’t appear to cut off any future directions<br class="gmail_msg">
> (e.g. submodules) since those are cross-file concepts that live between<br class="gmail_msg">
> internal/public or between fileprivate/internal.<br class="gmail_msg">
<br class="gmail_msg">
If we have Swift2's 'private' (instead of fileprivate) and 'scoped'(instead<br class="gmail_msg">
of current 'private'), then such 'private' can naturally mean "private to<br class="gmail_msg">
submodule" *especially* if file will be treated as un-named submodule.<br class="gmail_msg">
<br class="gmail_msg">
What we'll have with 'fileprivate' to have a submodule-wide access? New<br class="gmail_msg">
keyword 'submoduleprivate' ? Will extend meaning of proposed 'private' ?<br class="gmail_msg">
Rename 'fileprivate' to something else?<br class="gmail_msg">
Just wonder if this direction was really discussed and core team has some<br class="gmail_msg">
thoughts about this.</blockquote><div><br></div><div>Now that is a change I would 100% support when factoring in sub modules. I would support that even before submodules come around but would prefer it to wait for submodules.</div><div><br></div><div>-Shawn</div></div></div>