[swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Charles Srstka cocoadev at charlessoft.com
Tue Mar 21 00:48:18 CDT 2017


> On Mar 21, 2017, at 12:11 AM, Xiaodi Wu via swift-evolution <swift-evolution at 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—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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170321/969aa8c7/attachment.html>


More information about the swift-evolution mailing list