Sent from my iPhone
Begin forwarded message: > From: Goffredo Marocchi <pana...@gmail.com> > Date: 3 April 2017 at 22:39:25 BST > To: Douglas Gregor <dgre...@apple.com> > Subject: Re: [swift-evolution] Type-based ‘private’ access within a file > > +1 this brings some of the best points brought on both side of the private > and fileprivate arguments while also thinking of users approaching Swift from > other major programming language and fitting in with Swift's goal of > progressive disclosure. > > I like this idea very much (off-topic: almost as much as bringing back > argument labels in function/closure types ;)). > > Sent from my iPhone > >> On 3 Apr 2017, at 19:34, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hello Swift Community, >> >> In rejecting SE-0159, 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, 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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
