<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 19, 2017, at 7:29 PM, David Waite via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">A third point (which is a bit more complex/convoluted) is that fileprivate remained an essential language feature because it allows implementation in extensions, and allows a simple “friend”-like feature where types that need access to implementation details due to higher coupling could be bundled into the same file. Outside of a desire of a scoped ‘private’ simply to match the behavior of certain other languages, private is used to hide implementation details from other parts of a file, while file private exposes them within the file. </div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">There is a potential that file-private can lead to an explosion of complexity due to a large amount of “friendly types” being bundled into the same file. In that sense, ‘private’ was wrong because it was adding complexity at the file level, when really a new access level would possibly have been more productive to define at the at the small-group-of-files level - either via a friend access level or submodules. We still have the potential of unmanageable files due to friend types, but any additional access levels to aid with this problem would have to be weighed against a now significantly more complex access model including file and scoped private. In that sense, the inclusion of scoped private may indeed be harmful in that it increases the challenge of much more useful access levels being added to the language.</div></div></blockquote></div><br class=""><div class="">This is the core of what I have been saying. If we don’t address this need of “friendly types” in a swift-y way, we will have to keep coming back to the drawing board (either for “friend” or “protected” or “submodules”). I really like swift 2 private, but it did cause long files because all of the extensions and friends had to be stuck in the same file. What we are really missing is something that has the connotation similar to private, but allows access where needed.</div><div class=""><br class=""></div><div class="">I agree with most of what was said in this blog post from the swift devs:</div><div class=""><a href="https://developer.apple.com/swift/blog/?id=11" class="">https://developer.apple.com/swift/blog/?id=11</a></div><div class=""><br class=""></div><div class="">The main exception is that I disagree that ‘internal’ maps to the ObjC case where a second header was used (it doesn’t, and that is what is causing all of this trouble). Because internal is the default, it feels much too easy to accidentally use parts of a type which should only be used by extensions/subclasses/friend types. Remember, in an app (as opposed to a framework), internal is basically equivalent to public. With the second header, users of the contents of that header had to explicitly include it, which meant there was no chance of accidental use.</div><div class=""><br class=""></div><div class="">What we need is something which maps to that second header case while still keeping everything conceptually simple and swift-y.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>