<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=""><div class="">True, what I meant was a wider feedback - let's face it, there are many more Swift developers now than 2 years ago.</div><div class=""><br class=""></div><div class="">My objection is not to the documentation itself, but to the fact that I'm unnecessarily exposing an internal implementation detail to the rest of the module. Being able to hide it from the rest IMHO leads to better though-through API that is indeed meant to be exposed; whereas exposing internal details leads to allowing various quick hacks instead. We know these quick hacks very well from the ObjC world by accessing private parts of the object via duck typing or setting values via KVO.</div><div class=""><br class=""></div><div class="">At least this is my experience with which the less implementation details are exposed to the outer world, the better.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 17, 2017, at 8:54 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">That blog post starts out right away to say that it's a response to community feedback. Moreover, the scenario you describe was just as possible in 2014 as it is now. Finally, then as now, it's unclear why you consider documentation to be "not pretty." After all, your reader would need to consult the documentation before using a variable anyway.<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></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="gmail_msg"><div class="gmail_msg">I'm aware of this, but that's fairly a long time ago - before Swift was open source and had community feedback and before Swift was used widely among developers.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">To me, real-world use of the language has shown some flaws of missing a protected access control, mainly having to decide between having a variable internal or cramming all of the class extension into one file, making it a 3KLOC mess. Either solution is not pretty - now I have it split among several files with an internal variable commented as "Do not use, for private use of this class only."</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez <<a href="mailto:cheyo@masters3d.com" class="gmail_msg" target="_blank">cheyo@masters3d.com</a>> wrote:</div><br class="gmail_msg m_-6805318124205854687Apple-interchange-newline"><div class="gmail_msg"><div dir="auto" class="gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg"><a href="https://developer.apple.com/swift/blog/?id=11" class="gmail_msg" target="_blank">https://developer.apple.com/swift/blog/?id=11</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg">On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">How about removing fileprivate, getting Swift 2 meaning of private (as most people here now suggest) and add additional @protected annotation for those who want a more fine-grained solution:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><span style="font-family:Menlo;font-size:9px;font-variant-ligatures:no-common-ligatures" class="gmail_msg"><span style="color:rgb(186,45,162)" class="gmail_msg">@protected</span> </span><span style="font-family:Menlo;font-size:9px;font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)" class="gmail_msg">private</span> - members accessable only from the class/struct/enum/... and their extensions within the file</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><span style="font-family:Menlo;font-size:9px;font-variant-ligatures:no-common-ligatures" class="gmail_msg"><span style="color:rgb(186,45,162)" class="gmail_msg">@protected</span> <font color="#ba2da2" class="gmail_msg">internal</font></span> - again, but you can access it even from extensions and subclasses outside of the file within the entire module.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><span style="font-family:Menlo;font-size:9px;font-variant-ligatures:no-common-ligatures" class="gmail_msg"><span style="color:rgb(186,45,162)" class="gmail_msg">@protected</span> </span><span style="font-family:Menlo;font-size:9px;font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)" class="gmail_msg">public/open</span> - the same as above, but outside the modules.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">To me, this way most people here will be happy:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- those wishing the access control gets simplified - it in fact does, you don't need to use @protected, if you don't want to/need to.</div><div class="gmail_msg">- those who need a fine-grained solution, here it is.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="gmail_msg m_-6805318124205854687Apple-interchange-newline"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">Sent from my iPad<br class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg">On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg">On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg">While we’re bikeshedding, I’m going to add my two cents. Hold on to your hat because this might be controversial here.<br class="gmail_msg"><br class="gmail_msg">I think both ‘private’ and ‘fileprivate’ are unnecessary complications that only serve to clutter the language.<br class="gmail_msg"><br class="gmail_msg">It would make a lot more sense to just have internal and public only. No private, no fileprivate, no lineprivate, no protected. It’s all silly.<br class="gmail_msg"></blockquote><br class="gmail_msg">Eh, I've used `private` to keep myself honest in terms of going through some book-keeping functions instead of directly accessing a property.<br class="gmail_msg"></blockquote><br class="gmail_msg">This is exactly the kind of thing I like it for and why I hope we might be able to keep scoped access even if it gets a new name that ends up as awkward as fileprivate (allowing private to revert to the Swift 2 meaning).<br class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><br class="gmail_msg">- Dave Sweeris<br class="gmail_msg">_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></blockquote><br class="gmail_msg">_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></div></blockquote></div><br class="gmail_msg"></div></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg">_______________________________________________</span><br class="gmail_msg"><span class="gmail_msg">swift-evolution mailing list</span><br class="gmail_msg"><span class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a></span><br class="gmail_msg"><span class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class="gmail_msg"></div></blockquote></div></div></blockquote></div><br class="gmail_msg"></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>
</div></blockquote></div><br class=""></body></html>