<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><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><ul style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><li style="box-sizing: border-box;" class="">What is your evaluation of the proposal?</li></ul></div></div></blockquote><div>I am agains it. My rationale below.</div><div><br class=""></div><div><div>One of Ilya’s main points is that encapsulation is a core principle of OOP and that Swift lacks tools to implement this properly. I think the terminology is somehow unlucky here. Encapsulation more universally refers to bundling of data and code that operates of that data, and this is indeed one of the things that defines OOP as a programming style. However, it seems that Ilya refers to data hiding, which often accompanies encapsulation. I believe it is important to distinguish these two concepts. Encapsulation as I use here is a particular problem-solving style while data hiding (what Ilya stresses) is a technique for enforcing program correctness. It is also not true that data hiding is a fundamental component of OOP languages, some of the popular ones don’t have any data hiding (e.g. Python).</div><div><br class=""></div><div>Data hiding obviously has an important core function, which is, as I mentioned above — making sure that the program is correct, by only exposing the interface other components should have safe access to. Swift has data hiding, only the philosophy of that data hiding is a bit different from the mainstream implementations. The scope of the most restricted access is the file. If I understand the background of this design decision correctly, goal here is to allow the programmer to be as flexible as possible about what can access what but also to ‘force' them to think about their code design and code layout (by organising interrelated stuff by files). Is this an ideal decision to the problem? Certainly not — it imposes some inconveniences on the programmer and can also compromise code safety (as Illya points out). Is this a good, elegant decision? In my opinion, yes. </div><div><br class=""></div><div>I can also understand Illya’s point that a local scope access might improve code safety in certain cases. What I disagree with is that these cases are prominent or problematic enough to deserve such attention. Adding new access modifiers makes the rules of the language more complicated, but I seriously doubt that a ‘local’ specifier will make programmers significantly more productive or prevent any number of serious bugs. So far, arguments presented were more of the ideological nature and while they are formally correct, I do not think that the actual end effect is as dramatic as described. In addition, I would like to point out that ‘local’ is also only an approximation — it does not solve the safety problem entirely. It merely functions as an additional safeguard agains programmer error. The actual problem can be only solved by specifying full rules what is accessible from where and under which conditions. A system like that probably won’t be practical enough for everyday programming at this point.</div><div><br class=""></div><div>I also think that the comparison with ‘let/var’ as brough try Ilya is flawed — variable mutability concerns the basic design of the data structure/algorithm itself, while data hiding concerns the fragility of a data structure. I understand that the boundary between these two is very fluent, as one can portray fragility as design by encapsulating/hiding parts of the implementation. However, we are talking about actual implementations (e.g. variables, code etc. that the implementation use) rather then the abstract structure of implementations. </div><div><br class=""></div><div>To sum it up: Swift already supports an elegant data hiding mechanism which IMO solves the biggest issue: components are already shielded agains incorrect EXTERNAL use. It remains prone to incorrect use in the same file. As far as I am concerned, the practical consequences of this are negligible. I have some experience with languages that do not have any data hiding whatsoever and I can’t say that I ever had any issues with messing up the private and public interfaces — neither in my own code nor in code written in collaboration with other people. In this regards do not believe that ‘local’ will add anything of value to the language, however it will make the rules more complicated. </div></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><ul style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><li style="box-sizing: border-box;" class="">Is the problem being addressed significant enough to warrant a change to Swift?</li></ul></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><ul style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><li style="box-sizing: border-box;" class="">Does this proposal fit well with the feel and direction of Swift?</li></ul></div></div></blockquote><div class="">I do not know. The problem of code safety is a fundamental one, but I am not sure that Swift has ever had the ambition to solve all of them. For me, the offered solution is good enough. </div><div><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><ul style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><li style="box-sizing: border-box;" class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</li><li style="box-sizing: border-box;" class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</li></ul></div></blockquote><div>I have read the proposal, and participated in the original discussion. I can’t claim to have performed an in-depth study though. </div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">More information about the Swift evolution process is available at</p><blockquote style="box-sizing: border-box; margin: 0px 0px 16px; padding: 0px 15px; color: rgb(119, 119, 119); border-left-width: 4px; border-left-style: solid; border-left-color: rgb(221, 221, 221); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><div style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px;" class=""><a href="https://github.com/apple/swift-evolution/blob/master/process.md" style="box-sizing: border-box; background-color: transparent; color: rgb(64, 120, 192); text-decoration: none;" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a></div></blockquote><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">Thank you,</p><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">-Doug Gregor</p><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">Review Manager</p></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote></div><br class=""></body></html>