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 < swift-evolution@swift.org> wrote: > > On 8 Oct 2016, at 11:31, Haravikk via swift-evolution < > swift-evolution@swift.org> wrote: > > > On 7 Oct 2016, at 22:44, Tony Allevato via swift-evolution < > swift-evolution@swift.org> 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 > swift-evolution@swift.org > 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution