On Wed, Apr 5, 2017 at 4:31 AM Vladimir.S via swift-evolution < [email protected]> wrote:
> On 05.04.2017 7:02, Chris Lattner via swift-evolution wrote: > > On Apr 3, 2017, at 11:34 AM, Douglas Gregor via swift-evolution > > <[email protected] <mailto:[email protected]>> wrote: > >> Hello Swift Community, > >> > >> In rejecting SE-0159 > >> < > https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md > >, > >> 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. > >> > >> The design, specifically, is that a “private” member declared within a > >> type “X” or an extension thereof would be accessible from: > >> > >> * An extension of “X” in the same file > >> * The definition of “X”, if it occurs in the same file > >> * A nested type (or extension thereof) of one of the above that occurs > in > >> the same file > > > > 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. > > > > 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: > > > > - 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. > > > > - 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. > > > > - 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. > > > > > > 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. > > If we have Swift2's 'private' (instead of fileprivate) and 'scoped'(instead > of current 'private'), then such 'private' can naturally mean "private to > submodule" *especially* if file will be treated as un-named submodule. > > What we'll have with 'fileprivate' to have a submodule-wide access? New > keyword 'submoduleprivate' ? Will extend meaning of proposed 'private' ? > Rename 'fileprivate' to something else? > Just wonder if this direction was really discussed and core team has some > thoughts about this. 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. -Shawn
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
