[swift-evolution] Type-based ‘private’ access within a file

Thu Apr 6 12:10:28 CDT 2017

>> On Apr 5, 2017, at 6:54 PM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> On Wed, Apr 5, 2017 at 12:02 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>  - fileprivate should really become much more rare, which makes it more meaningful and significant where it occurs.  This was the original idea and intent behind SE-0025.
>> 
>> I would like to understand the reasoning here. I just looked back at SE-0025 and I see this same assertion, but I cannot find the reasoning. Could you explain it to me please?

The idea of a private member is that it’s only visible within the class that declares it. In languages where the class is traditionally declared all at once, that’s straightforward enough; however, the tradition of implementing swift classes as a series of extensions (currently) forces opening much more than should be to any other classes within the file.  If class B needs access to one private within class A, it also gets access to every single variable used by an extension to A, and every single function used by an extension outside the one it’s declared in. That’s way more visibility into the class than it should have.

>> 
>> Certainly I would love to make the *spelling* of “fileprivate” be entirely nonexistent. But all the lines of logic I have come up with lead inexorably to the conclusion that the *semantics* of “fileprivate” should be the common, de facto, access level that people reach for when they need encapsulation.
>> 
>> 1. Someone makes a file with a single type in it, and marks the implementation details “private”. At this point, it does not matter matter which meaning “private” has, they all work the same so far.
>> 
>> 2. The developer adds a free function to the file. Or an extension of another type. Or another type entirely. And they put it in the same file because it needs to work with the implementation details of the existing type.

IMO having a free function access the internals of an object is a huge code smell. It should almost always be a function on the object or the class. And I’d be highly skeptical of any architecture that requires one class to access another class’s privates directly.  In general, I’m fairly strongly opposed to having multiple externally accessible classes in the same file (probably influenced by having used Java through most of my education).

>> 
>> Now the difference between possible meanings of “private” matters. And if it is anything short of “fileprivate”, then the developer has to go back and change access levels. Things no longer “just work”.

Well, yes, that’s what I’d expect and want, and that’s the whole point of access levels. If I have a private member and want to use it in another class, I should have to make a conscious decision about whether to open up that member, add an externally visible one, or just do it a different way entirely. (One might argue based on that point that the fix-it to widen the access level is actually harmful.) I’m not sure what your point is here, but I think forcing the dev to stop and think about whether the access needs to be loosened is a *good* thing.

>> 
>> The alternative scenario is that one adds something to the file which doesn’t need privileged access to what’s already there. In which case the questions are, “Why put it in the same file at all?” and “If there is a good reason to put it in the same file, is there any *harm* in it being able to see private members?”

Again I’m not seeing your point. Yes, you should think twice about why it’s in the same file. Yes, there is harm because it can now see fileprivate members that it shouldn’t.

>> 
>> Most developers most of the time should not have to think about sub-file-level granularity. If things are in the same file it is because they need to work together closely. We should be able to mark members “private” and work with them across the file. This dramatically reduces the cognitive burden, and the amount of time spent fiddling with access levels.

Are you arguing for reverting to the Swift 2 definition of private = modern fileprivate? 

I’d argue exposing privates to everything in a file actually *increases* cognitive load because now I have to keep track of which classes are declared in the same file. If private has a sane meaning (initial declaration + “primary” extensions, the level under consideration here) only the class I know I’m working in has access. Much simpler and context-free.

>> 
>> With any meaning of “private” less than “fileprivate”, developers end up marking things “private”, then letting the IDE change it to “fileprivate” when the compiler complains. This tells me that people actually want the semantics of “fileprivate”, and they want it to be spelled “private”.

No, I’d say 99+% of the time that I have to make something fileprivate, it’s only for the benefit of same-file extensions, and the proposal we’re considering here would negate most of the need for that. Exposing those members to anything else that happens to be in the same file is an unfortunate failing of Swift’s access control. Given Swift’s emphasis on extension-based implementations, I expect many others are in the same boat.

>> 
>> The main exception, where people truly desire and intend for tighter-than-file encapsulation, is when certain invariants must be preserved, and should not be touched except by dedicated methods. And *that* is the important case worth making unambiguously explicit.

Unfortunately, for the most part you can’t really do that properly without allowing stored properties in extensions anyway, because either the variable(s) involved have to be fileprivate or the methods have to go in the primary definition. Either way, more things can access the state than should.

>> 
>> All the talk about calling out cross-type sharing within a file seems superfluous. That is one of the principle reasons for putting multiple types in one file to begin with. But preserving invariants, now *that* deserves a meaningful and significant syntax, ideally something loud that warns developers not to mess with it.
>> 
>> So, why exactly is there a desire to make the semantics of “fileprivate” rare?

Because it’s more broad than needed. Everything that should be restricted to the type but is declared in or used by an extension has to be fileprivate, exposing its private parts to every other class in the file. Extending `private` to cover same-file extensions lets classes at least put on some underwear.

>> 
>> Nevin
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20170406/242b4179/attachment.html>