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

[Shawn Erickson]

On Wed, Apr 5, 2017 at 6:53 AM David Hart <david at hartbit.com> wrote:

>
>
> On 5 Apr 2017, at 13:51, Shawn Erickson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> 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.
>
> 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.
>

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...)

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.).

-Shawn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170405/c1953a1c/attachment.html>