<div dir="ltr"><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,blinkmacsystemfont,'segoe ui',helvetica,arial,sans-serif,'apple color emoji','segoe ui emoji','segoe ui symbol';font-size:16px"><li style="margin-left:15px;box-sizing:border-box">What is your evaluation of the proposal?</li></ul><div><font color="#24292e" face="-apple-system, blinkmacsystemfont, segoe ui, helvetica, arial, sans-serif, apple color emoji, segoe ui emoji, segoe ui symbol" size="3">+ 1</font></div><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,blinkmacsystemfont,'segoe ui',helvetica,arial,sans-serif,'apple color emoji','segoe ui emoji','segoe ui symbol';font-size:16px"><li style="margin-left:15px;box-sizing:border-box;margin-top:0.25em">Is the problem being addressed significant enough to warrant a change to Swift?</li></ul><div><font color="#24292e" face="-apple-system, blinkmacsystemfont, segoe ui, helvetica, arial, sans-serif, apple color emoji, segoe ui emoji, segoe ui symbol" size="3">Yes</font></div><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,blinkmacsystemfont,'segoe ui',helvetica,arial,sans-serif,'apple color emoji','segoe ui emoji','segoe ui symbol';font-size:16px"><li style="margin-left:15px;box-sizing:border-box;margin-top:0.25em">Does this proposal fit well with the feel and direction of Swift?</li></ul><div><font color="#24292e" face="-apple-system, blinkmacsystemfont, segoe ui, helvetica, arial, sans-serif, apple color emoji, segoe ui emoji, segoe ui symbol" size="3">I'm not completely sure. </font></div><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,blinkmacsystemfont,'segoe ui',helvetica,arial,sans-serif,'apple color emoji','segoe ui emoji','segoe ui symbol';font-size:16px"><li style="margin-left:15px;box-sizing:border-box;margin-top:0.25em">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</li></ul><div><font color="#24292e" face="-apple-system, blinkmacsystemfont, segoe ui, helvetica, arial, sans-serif, apple color emoji, segoe ui emoji, segoe ui symbol" size="3">Mixed. I won't get into all of the things I wish it did or did not have. </font></div><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,blinkmacsystemfont,'segoe ui',helvetica,arial,sans-serif,'apple color emoji','segoe ui emoji','segoe ui symbol';font-size:16px"><li style="margin-left:15px;box-sizing:border-box;margin-top:0.25em">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</li></ul><div><font color="#24292e" face="-apple-system, blinkmacsystemfont, segoe ui, helvetica, arial, sans-serif, apple color emoji, segoe ui emoji, segoe ui symbol" size="3">I've followed the discussions and read the proposals.</font></div><div><font color="#24292e" face="-apple-system, blinkmacsystemfont, segoe ui, helvetica, arial, sans-serif, apple color emoji, segoe ui emoji, segoe ui symbol" size="3"><br></font></div><div><font color="#24292e" face="-apple-system, blinkmacsystemfont, segoe ui, helvetica, arial, sans-serif, apple color emoji, segoe ui emoji, segoe ui symbol" size="3">Overall, I don't think that this is necessarily ideal but I do believe that it would be a net positive for the reasons stated. `private` would become more common and `fileprivate` less. </font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 17, 2017 at 4:23 PM, Riley Testut via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><div><blockquote type="cite">I think its important to point out that its more than aesthetics: because the simple file and extensions scenario are so common, it forces us to use both private and fileprivate fairly regularly, which increases the total number of access control to work with on a daily basis. And I think that’s the important point. That’s why open is a success IMHO: because it only needs to be used rarely, it provided the required functionality without increasing the number of access modifiers that needed to be used regularly.</blockquote><br></div></span><div>I agree 100%. I’ve never been a fan of open, and still disagree with the rationale for why it was added. However, because it does follow Swift’s progressive disclosure emphasis, and because it does accomplish what it was designed to do, I’ve made peace with it.</div><div><br></div><div>Fileprivate is different. It was intended to be used rarely, as another form of progressive disclosure, and when it <i>was</i> used, it had meaning. However, as has been discussed many times, this is not the case. Fileprivate, for a multitude of reasons, is used far more frequently than anticipated (fileprivate is certainly used way more than private in my own projects), and as a result <i>loses </i>its meaning. When looking at a fileprivate declaration, there is no way to know whether it is intended to be exposed to separate types, or simply to extensions of the same type.</div><div><br></div><div>Again, I personally think access control was far simpler in Swift 2. However, because the idea of scoped access clearly has value to many developers, I am okay with adding that functionality to the language. By allowing extensions to access private variables, fileprivate has actual meaning again (which was the original intention) and is also something that many developers may never need to use.</div><div><br></div><div>FWIW, I really don’t view this proposal as just a stop-gap, I think accepting this proposal will genuinely be the <i>best</i> option for Swift in general. I personally don’t like the idea of renaming private to scoped, since I think private and fileprivate are better terms in general. I just want private member access in my extensions for God’s sake :^)</div><span class=""><br><div><blockquote type="cite"><div>On Apr 17, 2017, at 1:08 PM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-4620658109253845467Apple-interchange-newline"><div><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;float:none;display:inline!important">I think its important to point out that its more than aesthetics: because the simple file and extensions scenario are so common, it forces us to use both private and fileprivate fairly regularly, which increases the total number of access control to work with on a daily basis. And I think that’s the important point. That’s why open is a success IMHO: because it only needs to be used rarely, it provided the required functionality without increasing the number of access modifiers that needed to be used regularly.</span></div></blockquote></div><br></span></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>