<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><br class=""><blockquote type="cite" class=""><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="">1) private to the file (Swift 2 semantics)</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="">2) accessible only to the current type/scope and to extensions to that type that are in the current file.</div></div></blockquote></div><br class=""><div class="">Imho the old model had the benefit that it made things like C++ "friend" superfluous, so I prefer 1) over 2).</div><div class="">It is simpler, and from a pragmatic standpoint, it is much more useful:</div><div class="">You can always put code into another file if you don't want it to access private stuff.</div><div class=""><br class=""></div><div class="">2) Solves the problem of encapsulation for playgrounds, but that could be done in other ways — there could be an #eof statement for playgrounds, and maybe Swift will even have improved namespaces in the future...</div></body></html>