[swift-evolution] private & fileprivate

[Braeden Profile]

> 
> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.

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.

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.

> 
>> On 8 Oct 2016, at 13:28, Shawn Erickson <shawnce at gmail.com <mailto: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>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/004f5c39/attachment.html>