<div style="white-space:pre-wrap">How about making things more organized and move to syntax like this:<br><br>private(scope) decl <br><br>Where scope is optional and defaults to full private. Can take "file" and "type" values. I.e:<br><br>private (file) var i = 1<br>private func a()<br>private (type) func b()<br><br>This way we can have a very fine grained access levels and maintain a better structure. Who knows maybe in Swift 5 there will be need for more.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, 1 Dec 2016 at 12:08 Álvaro Monteiro via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div style="font-size:12.800000190734863px" class="gmail_msg">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" class="gmail_msg"><br class="gmail_msg"></div><div style="font-size:12.800000190734863px" class="gmail_msg">Let me try to be clear:</div><div style="font-size:12.800000190734863px" class="gmail_msg"><br class="gmail_msg"></div><div style="font-size:12.800000190734863px" class="gmail_msg">- 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" class="gmail_msg">- Typeprivate would be accessible through an extension inside the module.</div><div style="font-size:12.800000190734863px" class="gmail_msg">- 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" class="gmail_msg">- 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 gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Thu, Dec 1, 2016 at 9:31 AM, Tino Heth via swift-evolution <span dir="ltr" class="gmail_msg"><<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><span class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><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" class="gmail_msg">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 class="gmail_msg">Access control is no tool to offer real "protection" — it can't stop someone who wants to break a system.</div><div class="gmail_msg">Especially in the world of open source, it is merely an advice from the author not to do certain things.</div></div><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" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
<br class="gmail_msg"></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>