<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>+1 for the scope based access control of Swift as opposed to the type based access control of other languages and for the nice writeup by <span style="background-color: rgba(255, 255, 255, 0);">Matthew.</span></div><div><br></div><div>I remember type based access control being criticized 20ish years ago to not allow access to internals of related classes. C++ created friends for that, Eiffel had something similar, but I like Swifts scope based model better, especially with respect to extensions.</div><div><br></div><div>Putting closely related things in one file and unrelated things in different files seems like a nice solution to me.</div><div><br></div><div>And its worth to note that private already means different things in different languages. In Java it means class private, in other languages it means object private (Ruby, I think).</div><div><br></div><div>That said I occasionally miss "protected" in the sense of subclass accessible.</div><div><br></div><div>-Thorsten</div><div><br>Am 07.12.2015 um 15:41 schrieb Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>I was not sure how I felt about Swift's access control when it was first announced but it didn't take long for me to believe it strikes a pretty good balance between complexity and ability to hide implementation details.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">It follows a very straightforward scope-driven strategy. If it is extended further I would like to see any enhancements follow the same scope-driven strategy rather than being type-driven as is seen in other languages. Proposals along these lines might be interesting to consider and might be able to accomplish what you are hoping to accomplish while affording additional flexibility.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">In a language where distributing the implementation of a type across several extensions sometimes in different files a type-driven access control model doesn't make a lot of sense to me. I think it has a lot of potential to be confusing. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">What would it mean to limit access to a member to the type itself in Swift? Would an extensions in the same (or different) files be able to see the member? What about extensions in a different module? And what about subclasses? Subclasses probably wouldn't have visibility to them, but any discussion of something like this will probably lead to discussion of protected as well.</div><div id="AppleMailSignature"><br>Sent from my iPad</div><div><br>On Dec 7, 2015, at 7:45 AM, Ilya via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div>Also, one problem with the current approach is that it's all or nothing. The classes in one file see everything from the other classes, and it may be useful to limit that and share only some additional APIs with those related classes, but not all of the implementation details / internal state, while still hiding those same APIs from unrelated classes. Currently, there is no way of doing it, even when splitting code into separate files (the class state must be all in one place and can't be in an extension).<br><br>--<br>Ilya Belenkiy<br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 7, 2015 at 8:17 AM Ilya <<a href="mailto:ilya@harmonicsense.com">ilya@harmonicsense.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My main proposal was not to change the semantics of private (although I would like that) but to introduce a way to keep class implementation details inaccessible to anything outside the class. I think that it should still be possible and useful to have the current level of sharing (I would just name it differently, given what private usually means in other languages).<br><br>Just as it is convenient to group several related classes that can refer to each other's implementation details, it is very convenient to have several classes that don't do this but are still related in other important way, for example related APIs or classes that are based on the same implementation idea (like array based data structures).<br><br>Having all code in one place rather than jumping through many small files is a very nice thing to have because it really helps to keep everything consistent. The more manual work people have to do for consistency, the more likelihood that it won't be done.<br><br>--<br>Ilya Belenkiy<br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 7, 2015 at 12:21 AM John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Dec 5, 2015, at 8:39 PM, Ilya via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> I think the it would help a great deal to have an access level modifier that is really private and visible only inside the class itself. Right now, the only way to hide implementation details for a class is to hide the class code in a separate file, which is very inconvenient for several reasons:<br>
><br>
> 1) the meaning of the code changes depending on which file the class is in. It's very easy to accidentally expose class internal details and then call class elements that are meant to be used only inside the class. Having a keyword for class internals will allow the compiler to ensure that only the public API for the class is used from the outside world. The user can check types on his own, but it's better that the compiler does it automatically. Similarly, the user can check that only the proper APIs are called, but it's better that the compiler does it automatically.<br>
><br>
> 2) accessibility by file structure may cause some really short files.<br>
><br>
> 3) It's impossible to group related classes in one file but still hide implementation details inside each class<br>
><br>
> I think that it the best solution is to make private keyword do what it states -- keep the class element private to the class. But if it's really important to have a separate keyword for backward compatibility, it would be the next best thing.<br>
<br>
But on the flip side, with your proposed semantics for private, it would be impossible to write a group of related types, functions, and extensions that do need to refer to each other’s internal details without exposing those details to the entire module. That’s not really acceptable.<br>
<br>
The Swift language rule encourages you to put independent definitions in different files. That definitely means that, if you want to enforce very tight separation of concerns, you’ll end up with more and smaller files. You haven’t explained why that’s really a *problem*, though.<br>
<br>
John.</blockquote></div></blockquote></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=eLFMrKDT8iBxZ-2Fbnk-2BZqvSchNN-2FvYXdceA0T7VxwkAd8QJn-2Fbf-2BZHewgsbyhJg7VRh-2FIFco1XmDSy5txMLseiHN4HzyfGxyvV1-2F-2FdfExVugtV6JzIP3uCosVL28kIdBv8VxG4Ck51y-2FBWyLgiFJuVxI1VKdQFFK6WatCUHmAAuc6RczFh-2FBuODdBPKIQ6Wxt7nrda1kKAixYNV9Q1oxyLg3e3VyvYgioAsu483YZ3ns-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=Z0lfE0AvBRKWSDAcltP5-2FwA6tH7CtZqjBw6KQdxzh8UeEAuMESPncyStoaIO7wH-2BzLGB6ov1z5PhCHl3UETUFOmZ0vNIj-2BGMnk-2Fjrre55faAihA1Z59JAzUtw72OvV1tOdL9jYI4myCjgo7jkwDsPu8VDZfwRCN9fbmHyjLdjbfHvQt-2F1NY0ndvVcIhaNFZgqpxnD5bHipI71q3ngZXTguNsK2pydepf0hniz6NgDjM-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>