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

[Xiaodi Wu]

On Tue, Mar 21, 2017 at 12:48 AM, Charles Srstka <cocoadev at charlessoft.com>
wrote:

> 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
>

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170321/f9fffe2d/attachment.html>