[swift-evolution] Type-based ‘private’ access within a file

[Shawn Erickson]

On Wed, Apr 5, 2017 at 4:31 AM Vladimir.S via swift-evolution <
swift-evolution at swift.org> 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
> > <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170405/01893041/attachment.html>