Best summary I’ve read on this thread for days! :) > On Apr 5, 2017, at 6:54 PM, Nevin Brackett-Rozinsky via swift-evolution > <swift-evolution@swift.org> wrote: > > On Wed, Apr 5, 2017 at 12:02 AM, Chris Lattner via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
David James
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
