<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Oct 8, 2016, at 5:58 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>Very much agree with essentially all of that.<br><br>Personally, I'd also want to explore whether any submodule scope could just subsume fileprivate (i.e., files not otherwise in a submodule behave as though they are their own submodule for access control purposes) rather than occupy another slot between it and internal, but that's a discussion we can postpone until a submodule proposal takes shape.<br><br></div></blockquote><div><br></div><div>That's an interesting thought. Files are such a concrete unit of scope that I think I would still prefer to see the file level access control as well, but I'm open to seeing specifics of other ideas when the time is right (which afaik is not Swift 4 phase 1).</div><br><blockquote type="cite"><div><div class="gmail_quote"><div dir="ltr">On Sat, Oct 8, 2016 at 17:27 Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div class="gmail_msg"><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div><br class="gmail_msg">Sent from my iPad</div></div><div dir="auto" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">On Oct 8, 2016, at 3:24 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Sat, Oct 8, 2016 at 2:15 PM, Matthew Johnson <span dir="ltr" class="gmail_msg"><<a href="mailto:matthew@anandabits.com" class="gmail_msg" target="_blank">matthew@anandabits.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><span class="m_-4419262710070155488gmail- gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Oct 8, 2016, at 2:01 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-4419262710070155488gmail-m_-1269094128131469079Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Sat, Oct 8, 2016 at 12:02 PM, Karl 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 8 Oct 2016, at 16:47, Braeden Profile <<a href="mailto:jhaezhyr12@gmail.com" class="gmail_msg" target="_blank">jhaezhyr12@gmail.com</a>> wrote:</div><br class="m_-4419262710070155488gmail-m_-1269094128131469079m_3837719418597257116Apple-interchange-newline 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"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-4419262710070155488gmail-m_-1269094128131469079m_3837719418597257116Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg">I was thinking that the domains themselves could be associated with a domain, so you could create alternate domains which are also publicly-visible, but distinct from the default, “public” domain.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">For example, if you have a bunch of methods which should be visible to subclasses, but you don’t want them to clutter your regular interface. Perhaps they have names which are confusingly-similar to the public API. I believe that is what “protected” is typically used for.</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Yes, but “protected" was specifically put down by the core team, seeing that any code from outside the library should see the class as one well-designed whole, not something with complicated, visible implementation details. If your class-internal methods are confusing (and aren’t necessary for normal use), they shouldn’t be made public in any way. Subclasses would too easily confuse the distinction between your implementation methods and your public ones.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">For what it’s worth, I was only confused by “private” and “fileprivate” for a minute or two until I looked up the actual proposal. I haven’t had trouble with it, and it does actually provide more flexibility for code access at the file level than we had before. Even if the syntax is clunky.</div></div></div></blockquote></div><br class="gmail_msg"></span><div class="gmail_msg">I’m not saying that (file)private is confusing - it’s very clear about what it does. But it is limiting; anything that wants access to those semi-private details needs to live in the same file. That’s clearly not scalable. Enormous files many thousands of lines long are easy for the compiler to digest, but less easy for humans to understand and navigate. In fact, I believe this whole “file-based” access control originally came out of the compiler’s implementation details.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I'm interested in more information about this. What sorts of code have you been writing where a file would have to be thousands of lines long in order to accommodate `fileprivate`? Many entire modules are only thousands of lines long--is there a reason this code couldn't be refactored into a module of its own? As mentioned by Matthew, isn't this calling for some notion of submodules?</div></div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span>There are rather significant optimization barriers at module boundaries right now. These do not exist for the standard library due to its tight relationship with the compiler, but for the moment it is a non-trivial concern for 3rd party code that is performance sensitive. This is effectively a language pressure in the direction of larger modules, at least for some domains. (Hopefully this pressure will eventually be alleviated - there has been at least some talk in that direction)</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Great point. IMO, it'd be important to identify how much of the desire for additional varieties of access modifiers represent workarounds to compiler limitations, because we'd be better off making optimization across module boundaries work better if that's the root of the issue. Certainly, also, submodules are a discussion that, having made a brief appearance at the end of Swift 3 evolution, would be ripe for Swift 4 phase 2.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">As for this topic about additional access modifiers, I'd like to understand what current use cases motivate them that arise because the current syntax is insufficiently expressive, rather than compiler shortcomings or the lack of other features that are on the horizon. The latter sorts of motivation, IMO, would be more definitively addressed by tackling the root problem; adding additional syntax in order to work around compiler limitations seems as best inelegant.</div></div></div></div></div></blockquote><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div></div><div dir="auto" class="gmail_msg"><div style="direction:inherit" class="gmail_msg">I agree completely. We definitely don't want to add features motivated only by current limitations. </div><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div><div style="direction:inherit" class="gmail_msg">IMO there is plenty of motivation for submodules from a number of different angles. If we do add them I think allowing an access control distinction between submodule and whole module makes a lot of sense. That isn't sufficient motivation on its own of course, but is still very relevant to any discussion of any access level between fileprivate and internal. I also believe it is very likely to be the best and most natural solution. </div><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div><div style="direction:inherit" class="gmail_msg">That said, it's always good to keep pushing for better concrete examples and use cases.</div><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div><div style="direction:inherit" class="gmail_msg">As for the cross-module performance issue, I very much hope to see that solved independent of any new features (aside from perhaps some annotations that help the optimizer and give it more room to work by restricting our future options for change).</div></div><div dir="auto" class="gmail_msg"><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><span class="m_-4419262710070155488gmail- gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">What it would basically come down to is that the interface of the object would be separated in to blocks based on your access privileges. When viewing the interface, it wouldn’t look much different to an extension:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><b class="gmail_msg">access(public)</b> class TabController {</div><div class="gmail_msg"> var tabs : [Tab] { get }</div><div class="gmail_msg"> func closeTab(at: Int)</div><div class="gmail_msg">}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><b class="gmail_msg">access(TabBarStuff)</b> extension TabController {</div><div class="gmail_msg"> func close(tab: Tab)</div><div class="gmail_msg">}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I definitely want something between internal and fileprivate, at least. I don’t see any reason at all why objects shouldn’t be allowed to present optional “slices” of their interface to appropriate clients. In fact, that is what access control is all about. I just want to generalise it to allow for user-defined visibility scopes (as well as the default ones for public, module, file and scope). That leads to the question of what visibility those user-defined scopes would have; and if you leave them entirely open to adopt any scope (except themselves), then you end up with the ability to slice your API for different use-cases. Or we could be boring and limit them to the module they are defined in.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The whole reason I’m bringing this up is because I don’t like the “file” part of fileprivate. How I split my files up is a readability decision.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Karl</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></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" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div><br class="gmail_msg"></span></div></blockquote></div><br class="gmail_msg"></div></div>
</div></blockquote></div></blockquote></div>
</div></blockquote></body></html>