<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=""><div><blockquote type="cite" class=""><div class="">On Mar 26, 2017, at 10:43 AM, Matthew Johnson 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 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;" class="">On Mar 26, 2017, at 10:43 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><div class="">This reaches the crux of the issue, doesn't it? The Swift 2 design for access modifiers does exactly what you reject: that design is based on the premise that it is wise for file organization to follow encapsulation.<br class=""></div></blockquote><div 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;" class=""><br class=""></div><div 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;" class="">It's always a gamble speculating about the premise of someone else's design. That said, if I had to guess I would imagine maybe it had as much to do with the legacy of C-family languages and header files as anything else.</div></div></blockquote></div><div class=""><br class=""></div><div class="">I've seen people say this several times in access control threads, but personally, I don't think the use of files for access control is a "legacy" or a coincidence. I think it's a pretty smart move.</div><div class=""><br class=""></div><div class="">By its nature, the `internal` scope is already defined by files: There is a certain set of files which are compiled together to form the module, and those files all see the same `internal` scope. Unless we entirely abandon the idea of Swift as a fully textual language and move to a FoxPro-style system where code is stored in a structured database, this will always be true in Swift. I have a hard time imagining an environment for writing Swift code where there *aren't* files or some equivalent named-chunk-of-arbitrary-code unit of organization like the "pages" in a playground.</div><div class=""><br class=""></div><div class="">Using files to scope `private` is thus a natural extension of the `internal` scope's rules (one group of files defines the `internal` scope; one single file defines the `private` scope). It also happens to fit well with typical programmer behavior. Organizing your code into files by concern is generally considered a best practice, but files do not carry any other semantic meaning: there's nothing (else) in the language that forces you to put a given declaration in one file or another. So with file-based `private`, there are only two reasons to care about which file a piece of code is in—`private` access and subjective code organization—and these two things are usually aligned.</div><div class=""><br class=""></div><div class="">This point is actually implicitly acknowledged by, for instance, the submodule proposal Jonathan Hull put forth upthread, where each file is implicitly its own submodule if not declared to be part of a different one. Files aren't always the right encapsulation boundary, but they often are.</div><div class=""><br class=""></div><div class="">What *can't* file-based organization do, but explicit or implicit scope boundaries can? Well, they can't nest. But as I've previously argued, limiting access to the confines of a nested scope is often problematic because you can only address the current scope, not a surrounding scope; thus, sharing even one level up requires you to "overshare" with the entire file or even (if there's no `fileprivate`) the entire module. Unless you start building `friend`-like features, of course, but I believe John McCall already discussed why that's a bad idea:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">access control is never going to be sufficiently expressive to express constraints like "this method can only be called from this other method" — we actively would not want to encourage programmers to engage in that level of pedantry, because some of them will, and they'll make themselves miserable and accomplish nothing of value, and they'll blame Swift (correctly) for implying that it was important.</blockquote></div><div class=""><br class=""></div><div class="">We could, of course, introduce some kind of explicit declaration for private scopes. But why? Files usually match or at least approximate the desired boundaries, and when they don't already, they usually can be made to do so. Sometimes they can't, but that merely means you have to be careful. How much syntax should we really dedicate to a corner case, especially one that doesn't prevent anything from being written, but merely requires you to exercise caution?</div><div class=""><br class=""></div><div class="">
<span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-position: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; line-height: normal; border-spacing: 0px;"><div class=""><div style="font-size: 12px; " class="">-- </div><div style="font-size: 12px; " class="">Brent Royal-Gordon</div><div style="font-size: 12px; " class="">Architechies</div></div></span>
</div>
<div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div class=""><div class="">P.S. Unless I misunderstand your meaning, I believe that this statement in your later post:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">The implicit outer scope at the file boundary is one that only exists because it was introduced in Swift 2.</blockquote><br class=""></div><div class="">Is anti-historical. The file scope is as old as `private` (and access control) in Swift, which was part of Swift 1 beta 4: <<a href="https://developer.apple.com/swift/blog/?id=5" class="">https://developer.apple.com/swift/blog/?id=5</a>></div></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>