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

[Aaron Crespo]

I'm in favor of this as an alternative to the previous evolution. Having
worked on Swift projects I find that using `private` ends up being very
rare when using an extension based style, good intentions and `private`
definitions soon convert to `fileprivate` and never back. I think the goal
of progressive discovery and trying make the simplest most obvious case
work more often breaks down with respect to access control and an extension
based architecture. This was not the case in Swift 2 when `internal` and
`private` covered everything well with an extension based style. Having
mentored people learning swift this is a very surprising discovery, in a
language that tries to not be surprising. Barring the revert which I was in
favor of this should go a ways to making `private` more useful more often
and making `fileprivate` an advanced form of `private` (as intended)? and
more rarely used.

On Mon, Apr 3, 2017 at 2:34 PM, Douglas Gregor via swift-evolution <
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
>
> This design has a number of apparent benefits:
> + “private” becomes the right default for “less than whole module”
> visibility, and aligns well with Swift coding style that divides a type’s
> definition into a number of extensions.
> + “fileprivate” remains for existing use cases, but now it’s use it more
> rare, which has several advantages:
> + It fits well with the "progressive disclosure” philosophy behind Swift:
> you can use public/internal/private for a while before encountering and
> having to learn about “fileprivate”   (note: we thought this was going to
> be true of SE-0025
> <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>,
> but we were clearly wrong)
> + When “fileprivate” occurs, it means there’s some interesting coupling
> between different types in the same file. That makes fileprivate a useful
> alert to the reader rather than, potentially, something that we routinely
> use and overlook so that we can separate implementations into extensions.
> + “private” is more closely aligned with other programming languages that
> use type-based access control, which can help programmers just coming to
> Swift. When they reach for “private”, they’re likely to get something
> similar to what they expect—with a little Swift twist due to Swift’s heavy
> use of extensions.
> + Loosening the access restrictions on “private” is unlikely to break
> existing code.
>
> There are likely some drawbacks:
> - Developers using patterns that depend on the existing lexically-scoped
> access control of “private” may find this new interpretation of “private”
> to be insufficiently strict
> - Swift’s access control would go from “entirely lexical” to “partly
> lexical and partly type-based”, which can be viewed as being more
> complicated
>
> Thoughts? Volunteer?
>
> - Doug
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170405/3c27a51d/attachment.html>