<div style="white-space:pre-wrap">Yes. The proposal is about providing a more limited access that hides implementation details for an API. So anything that uses the API whether it is in the same file or not cannot see (and potentially misuse) the implementation of the API.<br><br>--<br>Ilya Belenkiy</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 14, 2015 at 1:40 PM Marc Knaup <marc@knaup.koeln> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">This is not true. Extensions in the same file as the type they extend can see all members of that type. They don't have to be internal. </p>
<div class="gmail_quote">On Dec 14, 2015 7:29 PM, "Matthew Johnson" <<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br></div><blockquote type="cite"><p dir="ltr">Well that would break the pattern where you split the implementation of a type across several extensions in the same file.<br>
This is also often done when declaring protocol conformance to break down the type into logical pieces. <br>
I don't want to be forced to squeeze everything into the same body and declare a list of a dozen protocol conformance at once.</p><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><br></div></div></blockquote></div>
</blockquote>No, it doesn't break that pattern at all. In that case you already need to declare members visible to all extensions internal. Nothing in this proposal will prevent you from doing that. We are discussing use cases where a *single* extension, etc has implementation details it wants to keep hidden from *everything* outside that single extension.<br><div><br></div></div></blockquote></div>
</blockquote></div>