<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 Oct 7, 2016, at 3:56 PM, Jordan Rose 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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Oct 7, 2016, at 15:15, William Sumner 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 class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 7, 2016, at 3:05 PM, Zach Waldowski 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 class=""><div class="" style="font-family: Arial;">I third this sentiment. fileprivate is a nice idea and very clearly has its uses (which is why the proposal got traction in the first place), but when combined with the other access levels, the language feature as a whole feels arbitrary. In practical use, files that I felt were nicely encapsulated and hiding implementation details are now a scattered mix of access levels, adding cognitive load and making the code look unorganized for having the gall to use extensions to split up functionality.<br class=""></div><div class="" style="font-family: Arial;"><br class=""></div><div id="sig40804545" class=""><div class="signature"><span class="font" style="font-family: arial, sans-serif, sans-serif;">Sincerely,</span><span class="font" style="font-family: arial, sans-serif, sans-serif;"></span><br class=""></div><div class="signature"><span class="font" style="font-family: arial, sans-serif, sans-serif;"> Zachary Waldowski</span><span class="font" style="font-family: arial, sans-serif, sans-serif;"></span><br class=""></div><div class="signature"><span class="font" style="font-family: arial, sans-serif, sans-serif;"> </span><span class="font" style="font-family: arial, sans-serif, sans-serif;"><a href="mailto:zach@waldowski.me" class="">zach@waldowski.me</a></span><br class=""></div></div></div></div></blockquote><br class=""></div><div class=""><div class="">Beyond the textual change of using a different modifier name, I don’t see how the encapsulation and organization of code could be affected. Really, there’s not much point in rehashing prior discussion of SE-0025 unless there’s a previously unconsidered angle.</div></div></div></div></blockquote><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I<span class="Apple-converted-space"> </span><b class="">strongly</b> agree with this sentiment. SE-0025 was<span class="Apple-converted-space"> </span><i class="">very</i> heavily discussed, and while many people were not satisfied with the solution we went with (including me!), it was what the core team and community converged on. I don't expect us to change access control again until and unless we decide to change the model in some way, and even then I think we'll want to go through extra effort to maintain compatibility with Swift 3. As has been mentioned repeatedly, the bar for source-breaking changes is much higher than it was in the first few months of swift-evolution.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I actually consider it very lucky that most of our changes so far have been fairly non-controversial. Everybody has a different idea of what would make Swift a better language, and all of us well-meaning. But when those ideas conflict, some group is going to end up unhappy. I'm actually very glad that (a) we haven't had too many of these cases, and (b) even when we have, people have been able to accept it and move on to contributing to the next issue.</div></div></blockquote></div><div class=""><br class=""></div><div class="">Strong agreement here as well. This proposal has been litigated numerous times already, and the bar for source-breaking changes is much higher now. To effectively re-open the discussion would require a proposal that significant changes the model with a lot of evidence that such a new model is a drastic improvement over what we have now. “Back out SE-0025” is not a viable option now.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div class=""><br class=""></div></body></html>