Swift 2’s access modifiers had a very simple ‘elevator pitch’ - “If you are writing code, by default everything within the module (app or library) your are working in can see it, but other modules cannot. If you want other modules to see features of your module, you make them public. If something is an implementation detail that even other parts of your module shouldn’t mess with, you make them private”
I think I would have trouble *just* describing private vs file private in that amount of space. One sign of the complexity was that even after a ridiculous amount of bike shedding, we couldn’t come up with better way to distinguish the two than to call one “fileprivate”. So I would say for the purposes of swift as a language suitable for learning, the change was harmful. Secondly, there are reasons to choose one versus the other, but the combination of the meaning of the keyword changing between swift 2 and 3 and the spelling of “fileprivate” means that the choice of one or the other doesn’t really communicate anything to a developer of a typical project - it appears to often be a matter of the legacy of the code as well as developer taste. That the choice between private and file private doesn’t illustrate intent is harmful to coordination. A third point (which is a bit more complex/convoluted) is that fileprivate remained an essential language feature because it allows implementation in extensions, and allows a simple “friend”-like feature where types that need access to implementation details due to higher coupling could be bundled into the same file. Outside of a desire of a scoped ‘private’ simply to match the behavior of certain other languages, private is used to hide implementation details from other parts of a file, while file private exposes them within the file. There is a potential that file-private can lead to an explosion of complexity due to a large amount of “friendly types” being bundled into the same file. In that sense, ‘private’ was wrong because it was adding complexity at the file level, when really a new access level would possibly have been more productive to define at the at the small-group-of-files level - either via a friend access level or submodules. We still have the potential of unmanageable files due to friend types, but any additional access levels to aid with this problem would have to be weighed against a now significantly more complex access model including file and scoped private. In that sense, the inclusion of scoped private may indeed be harmful in that it increases the challenge of much more useful access levels being added to the language. -DW > On Feb 18, 2017, at 11:57 PM, Jose Cheyo Jimenez via swift-evolution > <swift-evolution@swift.org> wrote: > > How exactly is the use of scope private harmful? > > Do you have specific examples when scope private was harmful? > > > >> On Feb 18, 2017, at 9:06 PM, Zach Waldowski via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> On Fri, Feb 17, 2017, at 07:52 PM, Jose Cheyo Jimenez via swift-evolution >> wrote: >>> I don’t think there is evidence that scope private in Swift3 is "actively >>> harmful”. >>> >> >> This thread would quite simply not exist if not to present exactly that >> evidence. It exists; we, the change's detractors, exist. >> >> Zachary >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
