<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 14 Feb 2017, at 08:28, Goffredo Marocchi <<a href="mailto:panajev@gmail.com" class="">panajev@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">I personally think that removing file private by itself does not solve the issue. We either put it all up for change (permissions levels and axis systems... including unsubclassable outside the module by default, warnings about overriding a default method only define in the protocol) and we look at a holistic situation admitting that what we have is not perfect or we just risk damaging the language over religious fronts that each declare to be Swiftier than the other.</div></div></div></blockquote><div><br class=""></div><div>Just to make it clear, I’m not suggesting removing <b class="">fileprivate</b> the access-level but <b class="">fileprivate</b> the keyword, and go back to Swift 2’s <b class="">private</b>. I honestly think its not that bad. As <b class="">Xiaodi</b> said it much better than me in another thread:</div><div><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div><i class="">The beauty of Swift 2's access modifiers was that they were based around files and modules, explicitly rejecting types and scopes as units for determining visibility. It seems at base there's a group of people who reject that decision altogether. […] The point of the other thread was that a sizable proportion of people are finding the old system to be elegant and a suitable basis for future enhancements such as submodules. Here, there's another proportion of people who want to dismantle the old design completely. […] At some point, we've got to stop relitigating this design.</i></div><div><i class=""><br class=""></i></div></div></blockquote>If we remove scope-based private, we are back in a simpler and elegant world of file/module scope.<br class=""><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="">We cannot just address every bit of things with a very specific and restrictive language feature unless we want to go to the C++ language lawyers land for real.</div><div class=""><br class="">Sent from my iPhone</div><div class=""><br class="">On 14 Feb 2017, at 07:08, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div class=""><br class=""></div><div class="">On 14 Feb 2017, at 07:06, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class=""></span><br class=""><blockquote type="cite" class=""><span class="">On Feb 12, 2017, at 12:35 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">_Potentially_ meaningful, certainly. But what I'm hearing is that it isn't actually meaningful.</span><br class=""></blockquote><span class=""></span><br class=""><span class="">Yes, for sure. That was carefully worded :-)</span><br class=""><span class=""></span><br class=""><blockquote type="cite" class=""><span class="">Here's why:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">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.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">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.</span><br class=""></blockquote><span class=""></span><br class=""><span class="">I see what you’re saying, but from a mechanical perspective, I disagree: seeing fileprivate in this (theoretical) world would be more meaningful than seeing private, because you know that there must be something in an extension that uses the member.</span><br class=""><span class=""></span><br class=""><span class="">That said, whether it is meaningful or not is really not the question. Assuming you agree that it would carry “some” meaning, the question is really whether or not that meaning carries its own weight in terms of complexity in the language footprint. I tend to think “no”.</span><br class=""><span class=""></span><br class=""><span class="">If you agree with “no", then Swift 4.x should eradicate fileprivate as a concept and that we should revert SE-0025 from Swift 4 mode. What to do with Swift 3.x still hangs in the balance of course.</span><br class=""></div></blockquote><div class=""><br class=""></div><div class="">Wouldn't 3.x mode just warn of the future deprecation?</div><div class=""><br class=""></div><div class=""><b class="">Xiaodi</b>: I'd be very tempted to write a proposal myself to revert SE-0025. But it's going to be unpopular and I don't feel like I have the same ease as you do to make the necessary points eloquently to convince as many people as possible. Do you have the time to write it? If not, I'd really appreciate some input from you: your points in this and the other thread have always matched mine but were much better expressed :)</div><br class=""><blockquote type="cite" class=""><div class=""><span class="">-Chris </span><br class=""><span class=""></span><br class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></body></html>