<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 16, 2016, at 7:23 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">On that last point, I would push back against calling it access inflation. If a member needs to be visible outside the file for whatever reason, it needs to have at least internal visibility. This is not at all "inflated" (implying that it's a workaround) but an explicitly contemplated part of Swift's access scheme.<br class=""></div></blockquote><div>But what happens when someone needs to make an extension outside of the module? For example, subclassing UIGestureRecognizer. Should things like setState: (which triggers a bunch of side effects and should never be called externally) be made public? The only two options in pure Swift 3 (it only gains it’s protected-style import from ObjC) are to make them public or to disallow subclassing outside the module (you have to call setState: as part of implementing a custom gesture recognizer).</div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class="">What you're arguing is that we should be able to expressly enumerate the specific files in which a member is accessible. This is a more granular system, but increased granularity is not in and of itself sufficient justification. After all, if more granularity is better--and this is an argumentum ad absurdum--why not demand that we be able to expressly enumerate the specific types that can access that member? why not the specific methods of those types? why not the specific scope? why not the specific line?<br class=""></div></blockquote>Actually, I am arguing almost the opposite. I had originally wanted a more granular system like 'protected’ from most languages. This proposal comes from a realization that file granularity is most likely good enough for real world use cases.</div><div><br class=""></div><div>What I am arguing is important:</div><div>1) The author’s ability to show which items should generally not be accessible/used, but are still provided/required for extension/subclassing purposes.</div><div>2) Requiring users of these items to acknowledge the author’s intent (by requiring ‘import hidden’) before using them</div><div>3) Terminology which has the correct connotation for this new behavior</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">It's all about what use cases are enabled or not at different points along this spectrum of granularity. So the question is, does your proposed scheme enable additional use cases that `internal` does not?</div></blockquote><div>It allows use of ‘hidden’ variables/functions from other modules. It also allows the author to show their intention that the variable/function is meant to be accessed elsewhere if needed for extension (vs. internal which is the default)… and it requires the user to acknowledge that intention.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class="">I'm not convinced that having access to a member at a use site when the declaration itself is totally under your own control, in the same module, is "brittle" is any meaningful sense.<br class=""></div></blockquote><div>What I mean by brittle is how much a change in one spot will ripple throughout your code by requiring other changes. It becomes a much larger issue when multiple people are working on a code base.</div><div><br class=""></div><div><br class=""></div><div>Thanks,</div><div>Jon</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Oct 17, 2016 at 09:51 Jonathan Hull 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">To put it more forcefully, I believe that ‘fileprivate’ currently suffers from the same problem that singletons do. That is, the main reason to make something ‘fileprivate’ instead of ‘private’ is to allow some sort of extension. It is highly unlikely that the point you were required to expose for that extension will not also be needed by other extensions. Both ‘internal’ and submodules would extend the boundaries of the problem from the file boundary to the module/submodule boundary… but the underlying problem still persists.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">If it is the module designer’s intent to limit extension, then fine, but it also often forces a design to be much more brittle and fragile than it needs to be. One of two things happens: extension becomes impossible or there is access inflation, giving inappropriate levels of access (usually combined with a note in the documentation saying not to use it).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Thanks,</div><div class="gmail_msg">Jon<br class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"></blockquote></div></div></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Oct 16, 2016, at 3:28 PM, T.J. Usiyan <<a href="mailto:griotspeak@gmail.com" class="gmail_msg" target="_blank">griotspeak@gmail.com</a>> wrote:</div><br class="gmail_msg m_-7858549722253900487Apple-interchange-newline"></blockquote></div></div></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg">I don't like this at all and it comes down to "<span style="font-size:12.800000190734863px" class="gmail_msg">what is hidden can also be unhidden</span>". This, to me, feels like it would create more confusion than it would address. Why not just use `internal` for `hidden` items? If we're ok with modifying import statements, why not simply have a command that imports `fileprivate` stuff? (not advocating for this).<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I think that submodules would have really helped with this issue and it is unfortunate that we couldn't get them in for swift 3. </div></div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Sun, Oct 16, 2016 at 4:34 PM, Jonathan Hull 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">I keep wanting a “protected” access level, but I must also admit that there was something really elegant about Swift 2’s access scheme (and I think most of us feel like the word ‘fileprivate’ feels out of place). I was thinking about how to mesh those two ideas, and I think I may have come up with a solution.<br class="gmail_msg">
<br class="gmail_msg">
I propose we replace ‘fileprivate’ with a new ‘hidden’ access level. Hidden would work exactly the same way as fileprivate does now, but adds the connotation that what is hidden can also be unhidden. By adding ‘import hidden TypeName’ to another file, that file also gains access to all of the hidden items of that type (kind of like if it was in the same file).<br class="gmail_msg">
<br class="gmail_msg">
#FileA<br class="gmail_msg">
import Foundation<br class="gmail_msg">
<br class="gmail_msg">
Struct A {<br class="gmail_msg">
private var x:Int<br class="gmail_msg">
hidden var y:Int //This is just like fileprivate, but can also be shared with other files<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
extension A {<br class="gmail_msg">
//y can be accessed here because they are in the same file<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
#FileB<br class="gmail_msg">
import Foundation<br class="gmail_msg">
import hidden A //This allows the entire file to see A’s hidden variables<br class="gmail_msg">
<br class="gmail_msg">
extension A {<br class="gmail_msg">
//y can be accessed here because of the ‘import hidden’ declaration<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
#FileC<br class="gmail_msg">
import Foundation<br class="gmail_msg">
<br class="gmail_msg">
extension A {<br class="gmail_msg">
//y can NOT be seen or accessed here because it is hidden<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
I think this is a fairly elegant solution to our protected dilemma, which also feels in sync with Swift 2’s file-based scheme. The key features:<br class="gmail_msg">
• Extensions no longer need to be piled in the same file if it is getting too long<br class="gmail_msg">
• Subclasses can be in their own file, but still have access to the necessary parts of their superclass<br class="gmail_msg">
• It communicates the author’s intent that the items are not meant to be visible to its users, but that it is expected to be used for extension/subclassing<br class="gmail_msg">
• It requires an explicit statement ‘import hidden’ to access the hidden variables. Safe by default, with override.<br class="gmail_msg">
• It is not bound by module boundaries (i.e. you could use it for subclassing classes from an imported module)<br class="gmail_msg">
• Roughly the same length as ‘private’ and ‘public’ so various declarations packed together are much easier to read (fileprivate breaks reading rhythm)<br class="gmail_msg">
<br class="gmail_msg">
Worth a formal proposal?<br class="gmail_msg">
<br class="gmail_msg">
Thanks,<br class="gmail_msg">
Jon<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<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">
</blockquote></div><br class="gmail_msg"></div>
</div></blockquote></div></div></div></div></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>