On Tue, Mar 21, 2017 at 12:48 AM, Charles Srstka <cocoa...@charlessoft.com> wrote:
> On Mar 21, 2017, at 12:11 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > Charles Srstka's added comment, while intriguing, poses a problem in > argumentation. One of the points being made above about the major advantage > of new `private` over `fileprivate` is precisely that new `private` is > invisible to extensions. If one "solves" the problem of having to use > `fileprivate` by making `private` visible to extensions, it may well be the > case that `fileprivate` is no longer commonly necessary--but one has also > reverted one of the major arguments in favor of new `private` in the first > place. > > > I don’t see making things invisible to extensions to be the benefit of > ‘private’ at all > This feature of new `private` is literally one of the two headline goals outlined in the proposal as it was approved. SE-0025 has written it into the opening sentence: "Scoped access level allows hiding implementation details of a class or a class extension at the class/extension level, instead of a file." It is absolutely an intended benefit of new `private`. That's just a factual statement. > —it’s for maintaining encapsulation with embedded types. i.e. things like > this: > > class Foo { > class Bar { > private var baz: String // <— ‘Foo’ doesn’t need to access this > } > } > > This just enforces good programming style. On the other hand, the problem > with extensions that people are talking about comes from using extensions > to separate sections of a type’s built-in code, mainly around protocol > conformances: > > class Foo { > private var bar: String > } > > extension Foo: Baz { > func requiredByBaz() { > doSomething(with: self.bar) // <— ruh roh > } > } > > The way I look at it, the extension feature was created with the idea of > extending someone else’s type in mind, but the community latched onto it as > a way to organize the parts of your own type, and Swift 3’s ‘private’ is > getting in the way of that. Broadening ‘private’ to reach in-module > extensions would solve this issue, and would *also* allow flexibility to, > when the code for an extension gets significantly large relative to the > rest of the type's code, split that part off into a different file without > needing to make your internal state visible to the entire module. Kill two > birds with one stone, so to speak. > > Charles > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution