[swift-evolution] private & fileprivate

[Karl]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161008/0e31b979/attachment.html>