<div dir="ltr"><div style="font-size:12.800000190734863px">I think the idea behind this proposal is quite the contrary. It is about conveying the right message through the use of an expressive access control that addresses common use cases and leaves behind fileprivate which IMHO is a C inherited way of thinking.</div><div style="font-size:12.800000190734863px"><br></div><div style="font-size:12.800000190734863px">Let me try to be clear:</div><div style="font-size:12.800000190734863px"><br></div><div style="font-size:12.800000190734863px">- Private would work the same way as it does now: it would not be accessible through an extension.</div><div style="font-size:12.800000190734863px">- Typeprivate would be accessible through an extension inside the module.</div><div style="font-size:12.800000190734863px">- Typeprivate would allow to abandon the odd fileprivate. Access level would be constrained to swift constructs (structs, classes and extensions) and not to a compiler artifact (file).</div><div style="font-size:12.800000190734863px">- Typeprivate would allow to address a very common use case: separate concerns of a swift struct/class through extensions and at the same time allow accessing private properties within this class/struct. At the moment you would have to have everything in the same file (and leverage fileprivate) or use internal and let it be accessible across the module. One good argument in favor of internal in these use cases would be that a given module should only be worried about what it exposes to consumers (public) and internally it's only a concern to the developers ("producers") of the module. I disagree with this because communication is one of the core tenets of swift and stating a property is internal just because is declared in another file is bizarre, unswift, error prone and it surely does not convey the right message the developer wants.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 1, 2016 at 9:31 AM, Tino Heth via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><div><br><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">It also means that anybody who want to access your private var will just have to write an extension to expose it.</div></div></blockquote></div></span>imho this is wrong thinking:<div>Access control is no tool to offer real "protection" — it can't stop someone who wants to break a system.</div><div>Especially in the world of open source, it is merely an advice from the author not to do certain things.</div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>