<div dir="ltr"><div>I should add, on the topic of looking at real-world evidence: the question we really want to answer is, "Are authors taking advantage of (or finding useful) the new distinction between private and fileprivate?" To me, that people are leaving the migrator's `fileprivate` in place suggests that in general they don't much know or care about this distinction.</div><div><br></div><div>AFAICT, implementing a warning when `fileprivate` is too broad answers a different question, "Is `fileprivate` still necessary in as many places as it seems now that `private` is still here?" But, that's just asking for a straightforward measurement of how often (file)private members are accessed outside the private scope. What it doesn't tell you is whether Swift users are finding the distinction between private and fileprivate to be meaningful. In fact, if this warning were to be implemented and a large swing happens in `private` vs. `fileprivate`, I'd argue that we'd just demonstrated that Swift users aren't paying attention to the distinction at all, just mashing the buttons.</div><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 12, 2017 at 2:35 PM, Xiaodi Wu <span dir="ltr"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>_Potentially_ meaningful, certainly. But what I'm hearing is that it isn't actually meaningful. Here's why:</div><div><br></div><div>If I see `fileprivate` and can understand that to mean "gee, the author _designed_ this member to be visible elsewhere inside the file," then it's actually meaningful. OTOH, if I see `fileprivate` and can only deduce "gee, the author mashed some button in his or her IDE," then it's not really telling me anything.</div><div><br></div><div>What you've said above, as I understand it, is that it's not currently meaningful to see `fileprivate` because the migrator is writing it and not the author. The improved approach you proposed is the additional warning. In that case, the compiler will help to ensure that when I see `fileprivate`, at least I know it's necessary. But that's only telling me a fact (this member is accessed at least once outside the private scope), but it's still machine-based bookkeeping, not authorial intent.</div><div><div class="h5"><div><br></div><div><br></div>On Sun, Feb 12, 2017 at 2:14 PM, Chris Lattner <span dir="ltr"><<a href="mailto:sabre@nondot.org" target="_blank">sabre@nondot.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I don't fully agree: you are right that that is the case when writing code. However, when reading/maintaining code, the distinction is meaningful and potentially important.<span class="m_7658213302943825792HOEnZb"><font color="#888888"><br><br><div>-Chris</div></font></span></div><div><div class="m_7658213302943825792h5"><div><br>On Feb 12, 2017, at 12:02 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>If the overwhelming use case is that developers should pick one over the other primarily because it looks nicer, then blindly click the fix-it when things stop working, then the distinction between private and fileprivate is pretty clearly a mere nuisance that doesn't carry its own weight.<br><div class="gmail_quote"><div dir="ltr">On Sun, Feb 12, 2017 at 13:33 Jean-Daniel via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><blockquote type="cite" class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg">Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="m_7658213302943825792m_-9113574476706781674gmail_msg" target="_blank">swift-evolution@swift.org</a>> a écrit :</div><br class="m_7658213302943825792m_-9113574476706781674m_7519834204090425122Apple-interchange-newline m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div style="word-wrap:break-word" class="m_7658213302943825792m_-9113574476706781674gmail_msg">On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="m_7658213302943825792m_-9113574476706781674gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><blockquote type="cite" class="m_7658213302943825792m_-9113574476706781674gmail_msg"><b class="m_7658213302943825792m_-9113574476706781674gmail_msg">Final</b><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div dir="auto" class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg">Can someone tell me what is the use of 'final' now that we have 'public' default to disallowing subclassing in importing modules? I know that 'final' has the added constraint of disallowing subclassing in the same module, but how useful is that? Does it hold its weight? Would we add it now if it did not exist?</div></div></div></div></div></blockquote><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><br class="m_7658213302943825792m_-9113574476706781674gmail_msg"></div><div class="m_7658213302943825792m_-9113574476706781674gmail_msg">As Matthew says, this is still important.</div><br class="m_7658213302943825792m_-9113574476706781674gmail_msg"><blockquote type="cite" class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div dir="auto" class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><b class="m_7658213302943825792m_-9113574476706781674gmail_msg">Lazy</b></div><div class="m_7658213302943825792m_-9113574476706781674gmail_msg">This one is clearer: if Joe Groff's property behaviors proposal from last year is brought forward again, lazy can be demoted from a language keyword to a Standard Library property behavior. If Joe or anybody from the core team sees this: do we have any luck of having this awesome feature we discussed/designed/implemented in the Swift 4 timeframe?</div></div></div></div></div></blockquote><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><br class="m_7658213302943825792m_-9113574476706781674gmail_msg"></div><div class="m_7658213302943825792m_-9113574476706781674gmail_msg">Sadly, there is no chance to get property behaviors into Swift 4. Hopefully Swift 5, but it’s impossible to say right now.</div><br class="m_7658213302943825792m_-9113574476706781674gmail_msg"><blockquote type="cite" class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div dir="auto" class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><b class="m_7658213302943825792m_-9113574476706781674gmail_msg">Fileprivate</b> </div><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><br class="m_7658213302943825792m_-9113574476706781674gmail_msg"></div><div class="m_7658213302943825792m_-9113574476706781674gmail_msg">I started the discussion early during the Swift 4 timeframe that I regret the change in Swift 3 which introduced a scoped private keyword. For me, it's not worth the increase in complexity in access modifiers. I was very happy with the file-scope of Swift pre-3. When discussing that, Chris Latner mentioned we'd have to wait for Phase 2 to re-discuss it and also show proof that people mostly used 'fileprivate' and not the new 'private' modifier as proof if we want the proposal to have any weight. Does anybody have a good idea for compiling stats from GitHub on this subject? First of all, I've always found the GitHub Search quite bad and don't know how much it can be trusted. Secondly, because 'private' in Swift 2 and 3 have different meanings, a simple textual search might get us wrong results if we don't find a way to filter on Swift 3 code.</div></div></div></div></blockquote><br class="m_7658213302943825792m_-9113574476706781674gmail_msg"></div><div class="m_7658213302943825792m_-9113574476706781674gmail_msg">I would still like to re-evaluate fileprivate based on information in the field. The theory of the SE-0025 (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md" class="m_7658213302943825792m_-9113574476706781674gmail_msg" target="_blank">https://github.com/apple/swif<wbr>t-evolution/blob/master/propos<wbr>als/0025-scoped-access-level.<wbr>md</a>) was that the fileprivate keyword would be used infrequently: this means that it would uglify very little code and when it occurred, it would carry meaning and significance.</div></div></div></blockquote><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><br class="m_7658213302943825792m_-9113574476706781674gmail_msg"></div></div></div><div style="word-wrap:break-word" class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg">Infrequent use and significance are orthogonal.</div><div class="m_7658213302943825792m_-9113574476706781674gmail_msg">I still think developers would declare all ivars private (this is less ugly and shorter), and then will happily convert them to fileprivate each time the compiler will tell them they are not accessible somewhere else in the file.</div><div class="m_7658213302943825792m_-9113574476706781674gmail_msg">As the code that try to access that ivar is in the same file anyway, it has full knowledge of the implementation details and there is no good reason it shouldn’t be able to access the ivar when needed.</div></div></div><div style="word-wrap:break-word" class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><br class="m_7658213302943825792m_-9113574476706781674gmail_msg"><blockquote type="cite" class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div style="word-wrap:break-word" class="m_7658213302943825792m_-9113574476706781674gmail_msg"><div class="m_7658213302943825792m_-9113574476706781674gmail_msg">We have a problem with evaluating that theory though: the Swift 2->3 migrator mechanically changed all instances of private into fileprivate. This uglified a ton of code unnecessarily and (even worse) lead programmers to think they should use fileprivate everywhere. Because of this, it is hard to look at a random Swift 3 codebase and determine whether SE-0025 is working out as intended.</div><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><br class="m_7658213302943825792m_-9113574476706781674gmail_msg"></div><div class="m_7658213302943825792m_-9113574476706781674gmail_msg">The best way out of this that I can think of is to add a *warning* to the Swift 3.1 or 4 compiler which detects uses of fileprivate that can be tightened to “private” and provide a fixit to do the change. This would be similar to how we suggest changing ‘var’ into ‘let’ where possible. Over time, this would have the effect of getting us back to the world we intended in SE-0025.</div><div class="m_7658213302943825792m_-9113574476706781674gmail_msg"><br class="m_7658213302943825792m_-9113574476706781674gmail_msg"></div><div class="m_7658213302943825792m_-9113574476706781674gmail_msg">-Chris</div><br class="m_7658213302943825792m_-9113574476706781674gmail_msg"></div>______________________________<wbr>_________________<br class="m_7658213302943825792m_-9113574476706781674gmail_msg">swift-evolution mailing list<br class="m_7658213302943825792m_-9113574476706781674gmail_msg"><a href="mailto:swift-evolution@swift.org" class="m_7658213302943825792m_-9113574476706781674gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_7658213302943825792m_-9113574476706781674gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="m_7658213302943825792m_-9113574476706781674gmail_msg" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br class="m_7658213302943825792m_-9113574476706781674gmail_msg"></div></blockquote></div></div>______________________________<wbr>_________________<br class="m_7658213302943825792m_-9113574476706781674gmail_msg">
swift-evolution mailing list<br class="m_7658213302943825792m_-9113574476706781674gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="m_7658213302943825792m_-9113574476706781674gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_7658213302943825792m_-9113574476706781674gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_7658213302943825792m_-9113574476706781674gmail_msg" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br class="m_7658213302943825792m_-9113574476706781674gmail_msg">
</blockquote></div>
</div></blockquote></div></div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div>