<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=""><div><blockquote type="cite" class=""><div class=""><br class="">On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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=""><br class=""></div><div class="">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><br class=""></div><div>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><br class=""></div><div>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><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 8 Oct 2016, at 13:28, Shawn Erickson <<a href="mailto:shawnce@gmail.com" class="">shawnce@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="white-space:pre-wrap" class="">I agree something like you suggest will give a lot of flexibility without - I think - the IMHO quirkiness of friends in C++. It seems like the access domains must? be limited to inside a module to avoid potential surprises from outside the module?<br class=""><br class="">-Shawn</div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sat, Oct 8, 2016 at 3:38 AM Karl 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"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 8 Oct 2016, at 11:31, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="gmail_msg m_-2508319568439994175Apple-interchange-newline"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg">On 7 Oct 2016, at 22:44, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">personally I thought `private` was fine the way it was when it meant `fileprivate` and I had no real need for `private` as it exists in Swift 3.<br class="gmail_msg"></blockquote><br class="gmail_msg">I have to agree with this; I wasn't especially comfortable with the change (or the eventual choice of keyword style) and in practice I just don't find it useful. I haven't used the new "private" even once since it was added, except by accident, the only form of private I use is fileprivate.<br class="gmail_msg"><br class="gmail_msg">I've happily embraced the conform through extension style in Swift, and really when it comes down to it the new private access level just isn't compatible with that style of development. It's only really useful for hiding details of something you add in one specific section, which I almost never do (and when I do I just mark it fileprivate in case I can re-use it).<br class="gmail_msg"><br class="gmail_msg">Maybe some people do find it useful, but I'd prefer fileprivate to be the default behaviour of private; the current (scoped?) private access level seems far more limited, thus more deserving of a less convenient keyword, or some kind of modifier on private. But personally I'd be fine with removing it, as I don't think it really adds anything that fileprivate doesn't already cover.<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" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></div></blockquote></div><br class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">Sometimes you have multiple types inside a single file (because you want to share some fileprivate stuff but not make it internal), so it’s handy for that.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">But you’re right that the syntax is totally ugly. I think access control is actually once of the biggest weak points of Swift - we should have a way for more arbitrary access control, similar to “friend classes” in C++. So then all of your types don’t need to be stuffed inside the same file in order to share semi-private implementation details. “Internal” is scoped to modules, but many people have also expressed the desire for sub-modules or namespaces and often resort to nasty things like caseless enums or empty structs (why nasty? because they don’t really define types - they’re just used for grouping purposes, and we should have a separate construct for that). So then we may need some way for these sub-modules to share some semi-private implementation details, etc…</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I would prefer if we could define some kind of access-domain, and you could assign members or types to those domains. We could possibly have some kind of user-defined access-domains, which you could opt-in to in order to see more details about a type (so you could expose it for subclassing purposes, like “protected”, or in any other more arbitrary way).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">So it might look something like:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><b class="gmail_msg">@access-domain TabBarStuff</b> // the domain itself has an access-domain</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">class TabController {</div><div class="gmail_msg"> var tabs: [Tab]</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> <b class="gmail_msg">access(public)</b> func closeTab(at: Int) { … }</div><div class="gmail_msg"> <b class="gmail_msg">access(TabBarStuff)</b> func close(tab: Tab) { … }</div><div class="gmail_msg">}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">// Another file. Must be in the same module due to access-domain “TabBarStuff”’s visibility</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">class Tab {</div><div class="gmail_msg"> unowned var controller : TabController <b class="gmail_msg">access(TabBarStuff)</b></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> func close() { <b class="gmail_msg">controller.close(tab: self)</b> }</div><div class="gmail_msg">}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">In this case, our API design means that in TabController.close(tab:), we will never get a Tab from a different TabController. This is a nice feature to have, but it requires TabController and Tab to share a member which is not visible to other types. Currently, that means we must have types or extensions scattered around in different files to accommodate for access levels.</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Karl</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=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>