> On Mar 21, 2017, at 12:11 AM, Xiaodi Wu via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
