<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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="">On Apr 11, 2017, at 10:39 PM, Chris Lattner 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=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">However, as of the core team meeting last week, it became clear that the priority of maintaining source stability (and thus, not massively thrashing source files in the 3->4 conversion) is an overriding concern.</span></div></blockquote></div><div class=""><br class=""></div><div class="">Okay.</div><div class=""><br class=""></div><div class="">I stand by my previous opinion that SE-0169 should be rejected. If we are to have two sub-file access levels, they should be highly differentiated so that they can serve different use cases. Scoped `private` serves very different use cases from `fileprivate`; SE-0169's `private` is basically a poor imitation of `fileprivate`.</div><div class=""><br class=""></div><div class="">Moreover, I think SE-0169's change to `private` would be just as disruptive as aliasing `private` to `fileprivate` (but keeping `fileprivate` and not changing any keywords in migration); it's simply easier to "sell" to people who are unhappy with the disruption.</div><div class=""><br class=""></div><div class="">If I believed that SE-0169 would make the language better, I would support it. If I believed that it was not as good as aliasing `private` and `fileprivate`, but genuinely would be easier for users to migrate, I would support it. But it really seems to me that its only advantage over `private`-`fileprivate` aliasing is that it will give us an excuse for the change instead of only being able to say "We made a mistake in Swift 3 and we're sorry". I don't think the long-term costs of having two similar-but-not-the-same access levels are worth the short-term gain of avoiding this criticism.</div><div class=""><br class=""></div><div class="">So I believe we should reject SE-0169 and instead change our documentation to recommend use of `fileprivate` unless `private` is specifically required. We should then freeze the access control design, with the possible exception of an additive submodule feature.</div><div class=""><br class=""></div><div class="">(And also decree that uttering the words "I propose that we change the private keyword" shall be punished by drawing and quartering.)</div><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class=""><div style="font-size: 12px; " class="">-- </div><div style="font-size: 12px; " class="">Brent Royal-Gordon</div><div style="font-size: 12px; " class="">Architechies</div></div></span>
</div>
<br class=""></body></html>