<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 20, 2017, at 8:26 PM, Charles Srstka 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=""><span 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; float: none; display: inline !important;" class="">the concern with extensions could be easily solved simply by giving extensions access to private members of the extended type as long as those extensions are in the same module/submodule (or file, if you prefer, but I don’t). This would probably eliminate almost all of the use cases for fileprivate, as well as freeing us from the sometimes clumsy situation where we’re rather artificially forced to use files as a scope, instead enabling us to organize code into files as is appropriate for the project.</span></div></blockquote></div><div class=""><br class=""></div><div class="">I think that many advocates of scoped private misunderstand critics' concerns about extensions.</div><div class=""><br class=""></div><div class="">One of the nice things about file-based `private` is that it allows access from extensions not only on the same type, but also on *other* types. For example, suppose I have a Book type and I want to allow them to be added to bookshelves:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>class Bookshelf {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// I'm using file-based private here</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private(set) var books: [Book]</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func addBook(_ book: Book) {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>book.bookshelf = self</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>books.append(book)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class=""><br class=""></div><div class="">I also want to have a removal method, but—much like `UIView` and `NSView`'s `removeFromSuperivew`—I want that method to be on `Book`, not `Bookshelf`. With file-based private, that's no problem—just drop the code in an extension in the same file:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>extension Book {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func removeFromBookshelf() {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>guard let shelf = bookshelf else { return }</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>shelf.remove(at: shelf.books.index(of: self)!)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>bookshelf = nil</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class=""><br class=""></div><div class="">When we talk about file-based private being "better for extensions", we're *not*—or at least not necessarily—talking about it being better for the pattern of splitting a type into several different extensions to group related code together. We're talking about the pattern of splitting a *concern* across several different *types* by extending all of them, taking advantage of Swift's flexible scoping to encapsulate details even when the type hierarchy doesn't match the encapsulation boundaries you want.</div><div class=""><br class=""></div><div class="">So allowing `private` members to be seen by extensions anywhere in a project doesn't address this issue; in fact, it actively and aggressively undermines it, making it impossible to encapsulate any implementation details at a scope smaller than a single type. For myself and others like me, it is the exact opposite of what we want.</div><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 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>
<br class=""></body></html>