<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 27, 2017 at 1:47 PM, Charles Srstka via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><blockquote type="cite">On Mar 27, 2017, at 12:00 PM, Ross O&#39;Brien via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</blockquote><div><blockquote type="cite"><div><font face="Helvetica"><span style="font-size:12px">&lt;snip&gt;</span></font></div></blockquote></div><br></div></div><div>Creates a mechanism that actually makes sense for what people are using ‘extension’ for, solves the scoping problems, eliminates the need for fileprivate, solves all the problems that people are complaining about.</div></div></blockquote><div><br></div><div>No it does not.</div><div><br></div><div>In addition to the protocol-conformance pattern that Ross describes, people also use extensions to let types declared elsewhere (even in another module!) work with types declared locally. So in Foo.swift we will have the implementation of Foo, as well as things like “extension String { /* Foo-related stuff */ }”.</div><div><br></div><div>The file-scope access level, which had been and should be spelled “private”, enables those extensions of external types to access implementation details of Foo to do their work. Thus Ross’s scheme does not eliminate the need for file-level visibility at all. In my view, what we really need is an access level *broader* than a single file, so that implementation details can be made visible across a select group of tightly-related files but not the rest of the module. However that is out of scope for Swift 4.</div><div><br></div><div>Nevin</div></div></div></div>