Sent from my iPhone
> On 21 Mar 2017, at 05:48, Charles Srstka via swift-evolution
> <[email protected]> wrote:
>
>> 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.
I cannot believe this proposal is putting scoped access' value into question
sigh (not you, you are making a point supporting it obviously :)).
> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
