<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 class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">This is certainly not what I wrote. What I said is that hiding the private interface becomes a practical concern on large scale, when you deal with projects or libraries. Swift already solves that issue with per-file and per-module visibility. And when editing the narrow scope (the file), one should make sure that one knows that they are doing (not unlike what you wrote yourself). </div></div></blockquote></div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">Why not automate it if we can?</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">Oh, I quite agree with you here. But I still don’t think that declaration scope access is really necessary to achieve this (because quite honestly, the future-Taras messages are best conveyed through documentation strings :) ). </div></div></blockquote><br class=""></div><div class="">Would you remove all type checking and rely solely on the documentation to make function calls? If you wouldn’t, exactly the same reasoning applies to *where* a function can be called.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">I do not believe that your example is even remotely appropriate. These problems are on a totally different scale. You can’t seriously mean the the lack of definition scope access poses challenges that are even remotely similar to those associated with the lack of type checking. </div></div></blockquote><br class=""></div><div class="">I can and I do. Data encapsulation is a cornerstone for object oriented programming for a very good reason.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">No compiler sugar will prevent people from using your internal APIs if they want to. </div></div></blockquote><br class=""></div><div class="">True, but the same applies to type checking. We should have real data encapsulation for exactly the same reason.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">At any rate, I can’t help but notice that we are going in circles here. </div></div></blockquote><br class=""></div><div class="">We are. I hope that my pull request with the proposal will be merged and reviewed soon. This issue has already received plenty of discussion here.</div></div></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 26, 2016, at 8:36 AM, Taras Zakharko <<a href="mailto:taras.zakharko@uzh.ch" class="">taras.zakharko@uzh.ch</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div></blockquote></div></div></div></div></div></blockquote><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">By this logic, you don't want or need private (Swift's private-to-file) either. You just want/need internal and public, because you trust your judgement and you want access to everything in the project.</div></div></div></blockquote></div></div></div></div></div></blockquote><br class=""></div><div class="">This is certainly not what I wrote. What I said is that hiding the private interface becomes a practical concern on large scale, when you deal with projects or libraries. Swift already solves that issue with per-file and per-module visibility. And when editing the narrow scope (the file), one should make sure that one knows that they are doing (not unlike what you wrote yourself). </div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">I'm not arguing that Swift needs, say, Scala's level of detail in its access modifiers, but I think an access modifier for private-to-class or private-to-instance or private-to-scope would let past-Rob convey useful information to future-Rob in a lot of places where currently the information is less precise or entirely absent, and that this ability is useful enough to justify the additional language complexity.</div></div></div></blockquote></div></div></div></div></div></blockquote><br class=""></div><div class="">Oh, I quite agree with you here. But I still don’t think that declaration scope access is really necessary to achieve this (because quite honestly, the future-Taras messages are best conveyed through documentation strings :) ). See also the summary at the end of my mail. Subclass scope is a different story, because it has many practical uses, but thats a topic for another discussion. </div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</blockquote><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">The reasoning is the same as having real types instead of conventions for naming objects:</div></blockquote><br class=""></div><div class="">I do not believe that your example is even remotely appropriate. These problems are on a totally different scale. You can’t seriously mean the the lack of definition scope access poses challenges that are even remotely similar to those associated with the lack of type checking. </div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">There are plenty of discussions about Cocoa private APIs on the web where the only thing that is stopping people is whether using them will pass the app store check (and if there is a secret back door still). That specific boundary is addressed with “internal”, but the same is true at the scale of a class.</div></div></blockquote><br class=""></div><div class="">No compiler sugar will prevent people from using your internal APIs if they want to. With Objective-C this is particularly easy, due to the dynamic nature of the language. Even if Swift had the definition scope access modifier, one could get access to your private interface by reverse-engineering the memory layout of your object and accessing the state directly. The only real argument in favour of definition scope is bug prevention, and as far as I am concerned, it is a matter of opinion (I do like your point about autocompletion though). Again, as I wrote before, I am ambivalent. I don’t think that Swift will loose anything by introducing definition scope access but I also don’t think that it will gain anything. </div><div class=""><br class=""></div><div class="">At any rate, I can’t help but notice that we are going in circles here. I think that the decision should be made by the core Swift team, who should evaluate how well it fits with their vision. </div><div class=""><br class=""></div><div class="">Best, </div><div class=""><br class=""></div><div class=""> Taras</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">This a great writeup on clarity of intent. I’d like to add that in principle, if clarity of intent was the only goal, it could be achieved by a universally agreed on convention, like putting _ in front of the method or property (or type) . We could put it in guidelines and rely on it in all Swift projects. The other part that it is enforced by the compiler is equally important. The reasoning is the same as having real types instead of conventions for naming objects:<div class=""><br class=""></div><div class="">Imagine that the Swift compiler did nothing for types — it was just a useful way to convey the coder’s intent. Maintaining the code in this context would become much more difficult:</div><div class=""><br class=""></div><div class="">1) the compiler would not help catch mistakes.</div><div class="">2) the tools would not provide contextual auto completions or useful type related information in general</div><div class=""><br class=""></div><div class="">I am sure that everyone would be less comfortable shipping a large codebase that didn’t go through all the type checks. Exactly the same reasoning applies to “local”. If it’s just a convention that is not enforced by the compiler, we lose a very useful way to verify code correctness. In addition to that, everything that is marked as “local” (or “_” in front of the name) now shows up in code completions and adds noise and temptation to cut corners (often this would be “faster” functions that already assume certain things about the state that may generally not be true). There are plenty of discussions about Cocoa private APIs on the web where the only thing that is stopping people is whether using them will pass the app store check (and if there is a secret back door still). That specific boundary is addressed with “internal”, but the same is true at the scale of a class.</div><div class=""><br class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra">I agree with everything Matthew Johnson said in his response. In addition:</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Jan 25, 2016 at 5:40 PM, Taras Zakharko via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Personally, I use it quite often because of the way I like to design things as groups of tightly interdependent components (friends, if you want) who are aware of each other’s inner workings. I also want to have full access to the interface of any project I work on because I trust myself to make the judgement whether I am allowed to use a particular functionality or not.</blockquote></div><br class=""></div><div class="gmail_extra">By this logic, you don't want or need private (Swift's private-to-file) either. You just want/need internal and public, because you trust your judgement and you want access to everything in the project.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">I trust my judgement, but I don't trust my memory. In six months, I won't remember every detail of the code I wrote today. Private-to-file is a message from past-me to future-me: "Dear future-Rob, you don't need to worry about looking for any use of this element outside this file, but if you want to make it visible to other files, you better study it to make sure it's safe to expose. Warmest regards, past-Rob."</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">This is a useful message. It helps jog future-Rob's memory, it saves future-Rob from bugs, and it lets past-Rob rest easy because the message is guaranteed to be delivered, and is guaranteed to be correct. No comment or policy or convention can make that guarantee.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">I want the ability to send another useful message: "Dear future-Rob, you don't need to worry about looking for any use of this element outside this class, but if you want to make it visible to other classes, you better study it to make sure it's safe to expose. Very truly yours, past-Rob."</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">Note that moving a private class to its own file to make its privates more private does not work. Now I have to make the formerly-private class an internal class, so I'm not sending the first message anymore.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">I'm not arguing that Swift needs, say, Scala's level of detail in its access modifiers, but I think an access modifier for private-to-class or private-to-instance or private-to-scope would let past-Rob convey useful information to future-Rob in a lot of places where currently the information is less precise or entirely absent, and that this ability is useful enough to justify the additional language complexity.</div><div class="gmail_extra"><br class=""></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>