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.
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. > On 8 Oct 2016, at 13:28, Shawn Erickson <[email protected]> wrote: > > 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? > > -Shawn > > On Sat, Oct 8, 2016 at 3:38 AM Karl via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> On 8 Oct 2016, at 11:31, Haravikk via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >>> On 7 Oct 2016, at 22:44, Tony Allevato via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> 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. >> >> 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. >> >> 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). >> >> 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. >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > 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. > > 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… > > 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). > > So it might look something like: > > @access-domain TabBarStuff // the domain itself has an access-domain > > class TabController { > var tabs: [Tab] > > access(public) func closeTab(at: Int) { … } > access(TabBarStuff) func close(tab: Tab) { … } > } > > // Another file. Must be in the same module due to access-domain > “TabBarStuff”’s visibility > > class Tab { > unowned var controller : TabController access(TabBarStuff) > > func close() { controller.close(tab: self) } > } > > 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. > > Karl > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
