<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>My 2c:</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">+1 to reverting private to the Swift 2 meaning and deprecating or using fileprivate as an alias for private.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">As a framework developer I am constantly deciding backward and forwards to go private only to realise that my embracing extensions makes it impossible to allow internal properties in private as we don't support stored properties in extensions. And, without it, I think private is overly hamstrung when defining classes and types with extensions. There is no difference to the compilation beyond a rule that the compiler enforces, but can optimise anyway. In which case, it is purely communicative, and is therefore practically useless because I can't declare the property the method uses in that extension anyway. And littering my code with the ugly fileprivate marker is just an annoying inconvenience.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">+1 also to add in something like 'protected'. It's a hole in the language where subclasses may have reasons to access but other types have no business touching.</div><div><br>On 18 Feb 2017, at 2:38 pm, Jonathan Hull via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">My ideal scenario:</div><div class=""><br class=""></div><div class="">1) Go back to Swift 2 meaning of private</div><div class=""><br class=""></div><div class="">2) Add the ‘hidden’ axis I talked about in another thread. &nbsp;</div><div class=""><br class=""></div><div class="">This will provide the capabilities of protected + friend (and allow extensions organized across files) using a consistent file-based approach that is easy to reason about. &nbsp;It also neatly avoids the issues mentioned in the blog post.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 16, 2017, at 10:47 PM, Jose Cheyo Jimenez via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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=""></div><div class=""><a href="https://developer.apple.com/swift/blog/?id=11" class="">https://developer.apple.com/swift/blog/?id=11</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class="">On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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="">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>&nbsp;</span><span style="font-family: Menlo; font-size: 9px; font-variant-ligatures: no-common-ligatures; color: rgb(186, 45, 162);" class="">private</span>&nbsp;- 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>&nbsp;<font color="#ba2da2" class="">internal</font></span>&nbsp;- 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>&nbsp;</span><span style="font-family: Menlo; font-size: 9px; font-variant-ligatures: no-common-ligatures; color: rgb(186, 45, 162);" class="">public/open</span>&nbsp;- 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 class=""><blockquote type="cite" class=""><div class="">On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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" class="">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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></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>_______________________________________________<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></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>