<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky <<a href="mailto:nevin.brackettrozinsky@gmail.com">nevin.brackettrozinsky@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Daniel, I would be interested to hear what, exactly, are the benefits your project has realized from the new “private” compared to the old “private” (which is now called “fileprivate”).<div><br></div></div></div></blockquote><div><br></div><div>There's no amazing insight here. The benefit is more granular control. The more people work on a project, the more useful this becomes.</div><div><br></div><div>You might as well ask "why not make everything public" if private and fileprivate makes no difference to you.</div><br><blockquote type="cite"><div><div dir="ltr"><div>Were there problems caused by the old “private” that have been solved by the new “private”? Major problems? Minor annoyances?</div><div><br></div><div style="text-align:center">• • •</div><div><br></div><div>As I see it, two significant drawbacks of the new “private” are increased complexity in the access control model, and encumbrance of the old “private” with the unwieldy moniker “fileprivate”.</div><div><br></div></div></div></blockquote><div><br></div><div>The first drawback is a truism: every language addition of feature makes it more complex. So we need to measure the benefit with other costs, which brings us to your second "drawback". I'm having a hard time understanding it. Is it too hard to type? If so, as an Objective-C survivor I disagree. The experience of reading code is harder and therefore more important than that of authoring code. "fileprivate" was chosen over many other alternatives because it's obvious to the reader. A shorter but equally obvious name would have been nice. But "unwieldy" is not enough reason to justify such source-breaking change at the moment.</div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div>If the new “private” has brought real benefits sufficient to outweigh its complexity cost then I think it should stay, and if not it should go. Thus I am curious to see what benefits it has in practice.</div><div><br></div></div></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div style="text-align:center">• • •</div><div><br></div><div>Regardless of whether the new “private” is pulling its weight, I believe we should find a shorter name for “fileprivate”.</div><div><br></div><div>And I think Xiaodi has the right idea: whensoever in the future we decide to introduce submodules, it would be best if they subsumed the file scope. In essence, a submodule would be the mechanism for parceling out code which currently must reside in a single file (because it relies on “fileprivate” which is the old “private”).</div><div><br></div><div>That way a submodule could comprise several interrelated pieces which need to share privy details, while preserving their natural separation into distinct files. So it makes sense that we should find a replacement for “fileprivate” which is copacetic to submodules.</div><div><br></div><div>Actually, now that I write it down, I wonder if perhaps “privy” might work as a keyword. It is short, it means “being party to shared secret knowledge”, and its spelling conveys a sense of “private-ish”.</div><div><br></div><div>The other ideas I’ve come up with have shortcomings, such as “local” which has a pre-existing incompatible meaning in programming (otherwise it would be great), or “folio” which is not an adjective (and also isn’t ideal for the single-file case).</div><div><br></div><div>But “privy” just might work.</div><div><br></div><div>Nevin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 13, 2016 at 10:44 PM, Daniel Duan 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 dir="auto"><div>I question the practicality of "<span style="background-color:rgba(255,255,255,0)">use private heavily simply because I don’t want the burden of mixing private and fileprivate". In our experience in converting a very mature Swift application, we had no choice but to use both because we </span><span style="background-color:rgba(255,255,255,0)">wanted private as much as possible but that's too restrictive in some cases. The granularity private and fileprivate provide is definitey a welcome change.</span></div><div id="m_5919248622795514714AppleMailSignature"><br><div>Daniel Duan</div>Sent from my iPhone</div><div><div class="h5"><div><br>On Oct 13, 2016, at 3:11 AM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><br><div><blockquote type="cite"><div>On 13 Oct 2016, at 08:25, Jean-Daniel via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_5919248622795514714Apple-interchange-newline"><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> a écrit :</div><br class="m_5919248622795514714Apple-interchange-newline"><div><div style="word-wrap:break-word">On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<div><blockquote type="cite"><div><div style="word-wrap:break-word"><div><blockquote type="cite" 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"><div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div 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">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><br></div><div>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><br></div><div><span class="m_5919248622795514714Apple-tab-span" style="white-space:pre-wrap"> </span>- Doug</div></div></div></blockquote></div><br><div>Not really. This proposal could be backed out without source-breaking changes by treating private as a synonym for fileprivate and we’d have Swift 2 behavior without breaking source. If the core team doesn’t want to consider that then we can just move on and live with it. </div></div></div></blockquote><br></div><div>Not speaking for the core team, just MHO:</div><div><br></div><div>I agree with Russ here, and with others who have said upthread that the “thing that has changed” is that we are starting to get usage experience with fileprivate vs private. I think we all understand the value of having fewer access control levels, and so if “private” isn’t conceptually pulling its weight, then it is reasonable to consider phasing it out.</div><div><br></div><div>That said, there is no specific rush to have this discussion, and I think it is reasonable to put a pretty high burden of proof on someone who wants to drive such a proposal. For example, if we had the discussion in the spring timeframe, we should have a pretty large body of Swift 3 code readily at hand (e.g. SwiftPM packages and other various github repos).</div><div><br></div><div>Given that, it should be easy enough to see how widely private is actually being used in practice. If it is very rare, then the argument to ditch it (make it a synonym for fileprivate, and eventually phasing out fileprivate) is strong. If lots of people are using private and only some are using fileprivate, then the discussion is quite different.</div><div><br></div><div>-Chris</div></div></div></blockquote><br></div><div>I don’t think monitoring the usage of private vs fileprivate is fair. By default, people will use private until they encounter visibility issues and discover they need to change to fileprivate. So private will probably being use far more than fileprivate.</div><div>Nonetheless it does not mean people chosen private because it effectively reduce the visibility to the class scope, but just because it is easier to discover and to type than fileprivate and fit in many cases.</div><br><div>I tend to write class will all ivars private by default (as it is a sensible default), and then, when I start to write extensions and other parts, I have to switch to fileprivate for a bunch of ivars. It create an inconsistent mess in my ivars declaration as it is difficult to know if an ivar is private because I has to be, or because I didn’t encounter a case that need it to be fileprivate instead.</div><div><br></div><div>Honestly, I don’t see any value in the introduction of fileprivate.</div><div><br></div><div><br></div></div>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br><div>I also agree that monitoring the usage of private vs fileprivate is not fair. I now use private heavily simply because I don’t want the burden of mixing private and fileprivate (and find the name of fileprivate slightly verbose/ugly). But that does not mean I would vote for keeping private. I would still vote for going back to Swift 2 behaviour. But I agree that we can wait until the summer to look at this again.</div></div></blockquote><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a></span><br></div></blockquote></div></div></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>
</div></blockquote></body></html>