<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div style="font-family:Arial;">Depending on the actual implications of the loosening of `private`, I'd then advocate for deprecating `fileprivate` in the Swift 4 timeframe and removing when it makes sense. Is that an option?<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">I am personally against muddying the implementation of access control further (in addition to its existing muddying in the syntactical sense, but let's avoid rehashing that now), and would like it if someone from the Core Team could speak to the complexities involved there. I wouldn't want access control changes to, for instance, hurt compile times or stymie ABI efforts.<br></div>
<div style="font-family:Arial;"><br></div>
<div id="sig40804545"><div class="signature"><span class="font" style="font-family:arial, sans-serif, sans-serif">Sincerely,</span><span class="font" style="font-family:arial, sans-serif, sans-serif"></span><br></div>
<div class="signature"><span class="font" style="font-family:arial, sans-serif, sans-serif"> Zachary Waldowski</span><span class="font" style="font-family:arial, sans-serif, sans-serif"></span><br></div>
<div class="signature"><span class="font" style="font-family:arial, sans-serif, sans-serif"> </span><a href="mailto:zach@waldowski.me"><span class="font" style="font-family:arial, sans-serif, sans-serif">zach@waldowski.me</span></a><br></div>
</div>
<div><br></div>
<div><br></div>
<div>On Mon, Apr 3, 2017, at 02:34 PM, Douglas Gregor via swift-evolution wrote:<br></div>
<blockquote type="cite"><div style="font-family:Arial;">Hello Swift Community,<br></div>
<div><br></div>
<div>In rejecting <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md">SE-0159</a>, 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.<br></div>
<div><br></div>
<div>The design, specifically, is that a “private” member declared within a type “X” or an extension thereof would be accessible from:<br></div>
<div><div><br></div>
<div><span style="white-space:pre;"></span>* An extension of “X” in the same file<br></div>
<div><span style="white-space:pre;"></span>* The definition of “X”, if it occurs in the same file<br></div>
<div><span style="white-space:pre;"></span>* A nested type (or extension thereof) of one of the above that occurs in the same file<br></div>
<div><br></div>
<div>This design has a number of apparent benefits:<br></div>
<div><span style="white-space:pre;"></span>+ “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.<br></div>
<div><span style="white-space:pre;"></span>+ “fileprivate” remains for existing use cases, but now it’s use it more rare, which has several advantages:<br></div>
<div><span style="white-space:pre;"></span>+ 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 <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a>, but we were clearly wrong)<br></div>
<div><span style="white-space:pre;"></span>+ 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.<br></div>
<div><span style="white-space:pre;"></span>+ “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.<br></div>
<div><span style="white-space:pre;"></span>+ Loosening the access restrictions on “private” is unlikely to break existing code.<br></div>
<div><br></div>
<div>There are likely some drawbacks:<br></div>
<div><span style="white-space:pre;"></span>- 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<br></div>
<div><span style="white-space:pre;"></span>- Swift’s access control would go from “entirely lexical” to “partly lexical and partly type-based”, which can be viewed as being more complicated<br></div>
<div><br></div>
</div>
<div>Thoughts? Volunteer?<br></div>
<div><br></div>
<div><span style="white-space:pre;"></span>- Doug<br></div>
<div><u>_______________________________________________</u><br></div>
<div>swift-evolution mailing list<br></div>
<div><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div>
</blockquote><div style="font-family:Arial;"><br></div>
</body>
</html>