<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 Feb 26, 2016, at 8:44 PM, Drew Crawford via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Threading is one especially pernicious case. If I have an ivar that is only safe for access from one thread, I *need* compiler enforcement. I *need* a guarantee that this ivar is only accessed through public interface methods that can be audited to be threadsafe. Simply a doccomment that says "bad programmer, don't do it" is not enough.</div></div></div></blockquote><div><br class=""></div>I’m unsure what you are imagining here - compiler protection of class details from within a closure completion handler that is also part of your class definition? I believe you would only get this with this local scope proposal if you structured your code such that callback blocks were functions outside your type definition.</div><div><br class=""></div><div>If you are talking about access or modification of the inner state of a class and a manual audit of safety, that audit is of the file and not of the type or extension. I’m unsure if your concern is of having to split code into multiple files for safety, or that there is not a way to split code into multiple files to achieve safety in some particular scenario.</div><div><br class=""></div><div><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="">This is not even a matter of "artistic choice" of whether or not I want to follow "one file per class". I can achieve thread safety with "private" ivars and "one file per class", but if my class is UITableViewCellContentView (which is an implementation detail that should be hidden even to most of UIKit) I am now forced to expose that implementation detail to my entire team.</div></div></div></blockquote><div><br class=""></div><div><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">This places me in the unconscionable situation of choosing between whether I have thread safety or encapsulation, between whether my coworker will accidentally create a threading bug or accidentally use a class they ought not to use and I am unable to appropriately hide.</div></div></blockquote><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></div></div>I’m not quite sure what you mean here - exposing that your class is a subclass of UITableViewCellContentView? Or that the rest of your team needs to code in different files from your class in order to maintain encapsulation?</div><div><br class=""></div><div>It may be that I’m unfamiliar with UITableViewCellContentView (as it is not documented).</div><div><br class=""></div><div><snip></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=""><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><ul class="" 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);"><li class="" style="box-sizing: border-box;">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</li></ul></div></blockquote><div class="">I've followed this from the earliest discussions. I've rethought my position somewhat in response to the growing uncertainty about dropping the NS prefix, which I think exposes some very real problems with visibility in Swift.</div></div><div class=""><br class=""></div><div class="">As that situation has developed, I no longer believe this proposal goes far enough. But it does go somewhere, and we should not stay where we are.</div></div></div></blockquote><div><br class=""></div>I don’t understand how an access control proposal pertains to changes in the Foundation public API. What is the ideal end state in your mind, and in what way is this a step toward that?</div><div><br class=""></div><div>-DW</div><div><br class=""></div><br class=""></body></html>