> On Feb 15, 2017, at 5:00 AM, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > >> On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution >> <[email protected]> wrote: >> >> Keeping with the spirit of Swift and staying consistent with its design, I >> see two plausible meanings for private: >> >> Private could mean either: >> 1) private to the file (Swift 2 semantics) >> 2) accessible only to the current type/scope and to extensions to that type >> that are in the current file. >> >> I don’t think we’ve ever evaluated and debated approach #2 systematically. > > For what it's worth: > > I was opposed to SE-0025, but since I lost, I have tried to use `private` > wherever it made sense, rather than fighting with the language. > > Sometimes, the change of keyword makes no difference. Other times, it's a > hassle, because I have to switch between `private` and `fileprivate` as I > redesign things, with little perceived benefit. I'd say the split between > these is about 50/50.
My experience has been the same. > On a few occasions, I *have* genuinely appreciated the SE-0025 version of > `private`. These involved cases where I wanted to ensure that instance > variables were only manipulated in certain ways, using interfaces I had > specifically designed to handle them correctly. For instance, I might have > two parallel arrays, and I wanted to make sure that I only added or removed > elements from both arrays at once. I could do this with `fileprivate` by > splitting the type into two files, but it was more convenient to do it in one. I generally keep one type to a file (although I make an exception as needed for nested types). As such, my expectation has been that someone editing the file is editing the type, and thus is required to understand the implementation details of the type. I don’t know of any way to have a compiler enforce that a developer understand what they are doing when working within an implementation. I don’t even think private helps as a cue to a developer that they are thinking with sensitive implementation details, because private and fileprivate behave so similar, and because fileprivate used to be private. Generally, if I were to want to mark characteristics of a type as unsafe to depend on/manipulate directly, it is the properties of the type. This is because in swift there isn’t really a distinction between an exposed property and a private data field other than access level. > > In these cases, switching to #2 would *completely* defeat the purpose of > using `private`, because the extensions would be able to directly manipulate > the private instance variables. I would no longer gain any benefit at all > from `private`. All of my uses would either fall into "makes no difference" > or "it's a hassle”. My case with SE-0025 was that it should be deferred until decisions around submodules were made. I still think if submodules are a potential feature, they can impact how code is structured enough that they could have supplanted the need for one of private/fileprivate with a submodule-level access control. If submodules are a probable feature, it makes sense to make any tweaks to access control to be part of that feature. -DW _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
