<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=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 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=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 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 language shouldn't dictate how to organize code. The existing solution is great for modules and libraries, but it doesn't work well at the level of a specific API.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 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=""></div></blockquote></div><br class=""><div class="">+1. One of my favorite things about Swift is much more flexible physical code organization and an established practice of moving away from one file per class and towards placing related code together regardless for various sense of “related”. </div><div class=""><br class=""></div><div class="">For example, one may choose to place extensions to a number of types adding conformances to the same protocol in a single file. I imagine physical layout like this is not uncommon in Swift code. This does not necessarily mean you want these extensions to see implementation details of each other. By adding a ‘scope’ access modifier we are able to properly hide these implementation details regardless of physical layout. </div><div class=""><br class=""></div><div class="">This also improves robustness if you later decide to modify the physical organization of your code without changing visibility of the implementation details of the extensions.</div><div class=""><br class=""></div><div class="">Matthew</div></body></html>