<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><a href="https://developer.apple.com/swift/blog/?id=11">https://developer.apple.com/swift/blog/?id=11</a></div><div><br></div><div><br></div><div><br>On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">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=""><br class=""></div><div class=""><span style="font-family: Menlo; font-size: 9px; font-variant-ligatures: no-common-ligatures;" class=""><span style="color: rgb(186, 45, 162);" class="">@protected</span> </span><span style="font-family: Menlo; font-size: 9px; font-variant-ligatures: no-common-ligatures; color: rgb(186, 45, 162);" class="">private</span> - members accessable only from the class/struct/enum/... and their extensions within the file</div><div class=""><br class=""></div><div class=""><span style="font-family: Menlo; font-size: 9px; font-variant-ligatures: no-common-ligatures;" class=""><span style="color: rgb(186, 45, 162);" class="">@protected</span> <font color="#ba2da2" class="">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=""><br class=""></div><div class=""><span style="font-family: Menlo; font-size: 9px; font-variant-ligatures: no-common-ligatures;" class=""><span style="color: rgb(186, 45, 162);" class="">@protected</span> </span><span style="font-family: Menlo; font-size: 9px; font-variant-ligatures: no-common-ligatures; color: rgb(186, 45, 162);" class="">public/open</span> - the same as above, but outside the modules.</div><div class=""><br class=""></div><div class="">To me, this way most people here will be happy:</div><div class=""><br class=""></div><div class="">- 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="">- those who need a fine-grained solution, here it is.</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><br class="">Sent from my iPad<br class=""><br class=""><blockquote type="cite" class="">On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">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=""><br class="">I think both ‘private’ and ‘fileprivate’ are unnecessary complications that only serve to clutter the language.<br class=""><br class="">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=""></blockquote><br class="">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=""></blockquote><br class="">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=""><br class=""><blockquote type="cite" class=""><br class="">- Dave Sweeris<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>