Sent from my iPhone > On 4 Apr 2017, at 01:01, David Waite via swift-evolution > <[email protected]> wrote: > > Soft -1 for four reasons: > > 1. I would expect private to be used to hide implementation details and type > invariants from all code, to encapsulate and protect the unsafe bits. Think > the possibility to put the instance into an illegal state, or to modify its > state outside of its defined threading model. Why would an extension be > trusted to do this? This smacks of a ‘protected’ mode for extensions.
Not everybody would hate that ;), but seriously it seemed a strong request in all our discussions about this and it comes at a very small cost. > > 2. This makes the model more confusing, and increases overlap with file > private. It seems this is here just to appease the people who think > “fileprivate” is an ugly wart, while not having time to formulate a strategy > to eliminate file private. The real issue is that there isn’t a level between > fileprivate and internal. > > 3. This seems to make the issue of large files even worse, by encouraging the > use of ‘private’ as a way of exposing an extension-specific API of a type > that is only accessible by putting extensions in the same file > > 4. From discussions on migration, I believe we can leave the option open of > widening private later as part of a tasked redesign of access control after > Swift 4.0. I’d prefer to not widen private before we have evaluated access > control as a whole, as I believe private as it is today is the lowest, most > restrictive-but-usable level of access control. I am not sure this kind of change will easily happen for Swift 5, I say let's not waste this chance. > > -DW > >> On Apr 3, 2017, at 12:34 PM, Douglas Gregor via swift-evolution >> <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
