<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;">Pretty bummed out about the rejection. I know it's a petty aesthetic issue, but thinking about having to write "fileprivate" 5 or 10 years from now kills more of my enthusiasm about using the language than I'd like to admit. I think it's going to always be viewed by most as a major wart on an otherwise great language. Hopefully we can be more careful in the future about letting this sort of thing get through in the first place.
<div><br /></div>
<div>All that said, I'll support a proposal along the lines of what's being suggested.</div>
</div>
<div name="messageSignatureSection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;"><br />
Jarod</div>
<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;"><br />
<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;">
<div class="">
<div class="">
<div>On Apr 3, 2017, at 12:34 PM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br />
<blockquote type="cite" class="" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #e67e22;"></blockquote>
<br />
Hello Swift Community,<br />
<br />
In rejecting <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md" class="">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 />
<br />
The design, specifically, is that a “private” member declared within a type “X” or an extension thereof would be accessible from:<br />
<br />
* An extension of “X” in the same file<br />
* The definition of “X”, if it occurs in the same file<br />
* A nested type (or extension thereof) of one of the above that occurs in the same file<br />
<br />
This design has a number of apparent benefits:<br />
+ “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 />
+ “fileprivate” remains for existing use cases, but now it’s use it more rare, which has several advantages:<br />
+ 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" class="">SE-0025</a>, but we were clearly wrong)<br />
+ 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 />
+ “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 />
+ Loosening the access restrictions on “private” is unlikely to break existing code.<br />
<br />
There are likely some drawbacks:<br />
- 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 />
- 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 />
<br />
Thoughts? Volunteer?<br />
<br />
- Doug<br />
_______________________________________________<br />
swift-evolution mailing list<br />
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br />
<div class="">https://lists.swift.org/mailman/listinfo/swift-evolution</div>
</div>
</div>
</div>
</blockquote>
</div>
</body>
</html>