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

[Sean Heber]

This analysis feels pretty right to me and I’m not convinced we even *need* anything more restrictive than a file-wide private. If you want to lock some implementation detail up tight to keep something safe, then it might be a sign that you should refactor that type and pull that critical bit of logic out into it’s own file and type and use composition instead.

l8r
Sean


> On Apr 5, 2017, at 11:54 AM, Nevin Brackett-Rozinsky via swift-evolution <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> 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?
> 
> 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.
> 
> 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”.
> 
> 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?”
> 
> 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.
> 
> 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”.
> 
> 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.
> 
> 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?
> 
> Nevin
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution