<br><div class="gmail_quote"><div>On Wed, Apr 5, 2017 at 6:53 AM David Hart <<a href="mailto:david@hartbit.com">david@hartbit.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg">On 5 Apr 2017, at 13:51, Shawn Erickson 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"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">On Wed, Apr 5, 2017 at 4:31 AM Vladimir.S 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"></div><blockquote class="gmail_quote gmail_msg" 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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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></div></div></blockquote></div><div class="gmail_msg"><div class="gmail_msg">But the core team said there will not come back on their decision. We should discuss what can be done instead, not repeat the same arguments and opinions which bring us nowhere.</div></div></blockquote><div><br></div><div>Ok to be clear. I do not support changing private the way outlined in this proposal nor do I support reverting to swift 2 style. I do not want to paint us further into the corner on depending on file based access control. So if not other options remain on the table then in my opinion stay with what we have at this point. It is clear and explicit with wording that make some unhappy but gives the most folks tools that they want. (still depending of file constructs which I don't like but so be it...)</div><div><br></div><div>If submodules are on the table in the future ... then something like the following makes a lot on sense to me: We have the migrator change "fileprivate" to "private" and make this "private" mean accessible by the current submodule (currently defined to be in current file). We have the migrator change "private" to "scope[d]" keeping the current meaning of private. Then work on something like a submodules concept that allows subscoping inside of a module and/or enhance private (newly named private) to work across files for those things that make sense (subclasses, extensions, etc.).</div><div><br></div><div>-Shawn</div><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 class="gmail_msg"><div class="gmail_msg"></div></div></blockquote></div>