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

[Colin Barrett]

I'm broadly in favor of this.

On Mon, Apr 3, 2017 at 2:35 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
>

I think it might not as complicated as it may first appear. I haven't fully
convinced myself of this, but I believe that it would be lexically
scoped *modulo
inlining extensions*.

To put it somewhat more formally (and awkwardly), if one imagines a textual
transformation which blindly inlines any extension in a single file into
their type definitions (should those definitions occur within that file)
then accessing a "private" member in the original file would compile if and
only if the access would be lexically scoped if the above postulated
transformation were to be applied to it.

This is a pleasing property (to me anyway) as it means that it is unlikely
(impossible?) for moving code from one extension (or definition) to another
to cause a compilation failure.

Take this with a grain of salt of course, as there's probably an edge case
I'm not thinking of :P (This is why we write proofs!)

Cheers,
-Colin


> 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/20170406/e26b51f5/attachment.html>