<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div><br>On Oct 29, 2017, at 5:29 PM, Mike Kluev <<a href="mailto:mike.kluev@gmail.com">mike.kluev@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On 29 October 2017 at 16:04, Adam Kemp <span dir="ltr"><<a href="mailto:adam.kemp@apple.com" target="_blank">adam.kemp@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div></div><div>Internal is the right choice here. If it gives too much access then you might consider pulling this code into a separate module.</div><div><br></div><div>If “private” gave access to every extension then any code outside your module could make a new extension and access that method. That would make it effectively public in that you wouldn’t have any ability to limit who can call it.</div><div><div class="gmail-h5"><div><br></div></div></div></div></blockquote><div><br></div><div>there are two very different use cases for which we use extensions.</div><div><br></div><div>1) the extensions i use to split implementation of my own classes into different parts and / or files. for the sake of this discussion let's call this type of extensions a "continuation". </div></div></div></div></div></blockquote><div><br></div><div>Internal is sufficient for this use case. </div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>2) the extensions that are used to extend other people classes or system classes. this matches what we have now.</div></div></div></div></div></blockquote><div><br></div><div>There’s no need for a new access level here. If it’s in the same module then you use internal. If it’s not then you shouldn’t be able to access anything other than public API. </div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>speaking of (1) the naïve newcomers from C++ land would consider these continuations the same as splitting their C++ class implementation into separate files. e.g. the expectation is having an ability to access "private" members. if such a thing existed in swift at all it wouldn't be unimaginable having an ability to add variables in these continuations the same way as in the class itself. here "protected" access level would be a reasonable addition, and if we want to be totally nitpicky "protected" would be for subclasses and some other keyword, say, "extensionprivate" or "domestic" for continuations.</div></div></div></div></div></blockquote><div><br></div><div>Protected is a different concept entirely. <span style="background-color: rgba(255, 255, 255, 0);"> I’m not sure what the reasoning was for leaving it out. </span>Personally I do think protected is a useful access level so that you can clearly define API intended for subclasses. However, protected has nothing to do with extensions. It doesn’t solve that use case. </div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>an interesting challenge would be somehow prohibiting external people adding continuations to your own classes :)</div></div></div></div></div></blockquote><div><br></div><div>That was my original point. This is what internal does. We don’t need any new access levels for extensions. Internal solves these use cases. Code in the same module can be maintained in lockstep so you can make things internal as needed for extensions. Anything beyond that is effectively indistinguishable from public so just call it that. </div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Mike</div><div><br></div></div></div></div>
</div></blockquote></body></html>