<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 23, 2016, at 3:14 PM, 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"></blockquote><snip><br class=""><blockquote type="cite" class=""><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=""> With a file based access control, the only way to tell if an API is really private or can be safely used anywhere in the same file is to read the comments / source code. And it’s much easier to miss in maintenance, debugging, or code reviews. The only way to make it obvious in the current model is to adopt a convention like _ in front of methods.</blockquote></div></div></div></blockquote><div><br class=""></div><div>Within the same file, I would expect a member of my team writing code has the domain knowledge to do so correctly.</div><div><br class=""></div><div>Is the primary use case meant for files which have grown too large/complex for the authors to be expected to comprehend the type state invariance of the code they are currently working on?</div><div><br class=""></div><div>Or is the thought that developers may add code to the file to get access to private api (and implicit action), while they would not be willing to edit the access levels to do so otherwise (an explicit action)? This sounds like a process issue within a team, as access control flags will not necessarily restrict the process of modifying the code in certain ways for people who are already tasked with such without such external process/ramifications in place.</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=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span class="" style="font-family: Avenir-Book; float: none; display: inline !important;">There's nothing </span><span class="" style="font-family: Avenir-Book; float: none; display: inline !important;">about extending a class that ought to raise a red flag in Swift, because </span><span class="" style="font-family: Avenir-Book; float: none; display: inline !important;">it's perfectly legit to do so and use only the class' public APIs.</span></blockquote></div><div class=""><br class=""></div><div class="">Unless the programmer extends a class in the same file. Then he can call anything marked private, and it’s impossible to tell without reading the code whether it violates the class invariants. There is no way to express this in Swift today. My proposal for local / scoped access control would solve this.</div></div></div></blockquote><div><br class=""></div>There is nothing about someone editing that file to change a “local" access modifier to “internal" which will raise a red flag with Swift. Is this something that you plan to detect and block via a SCM commit hook/code review product?</div><div><br class=""></div><div>-DW</div></body></html>