[swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Brent Royal-Gordon]

> On Apr 6, 2017, at 5:38 PM, Charles Srstka via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> `private` works for extensions exactly how the authors of SE-0025 intended it to do. Your comments do not address what would happen for those people who are making use of this functionality currently to isolate methods to the extension only.
> 
> Who is currently doing that?

Me.

Even though I think we were better off without scoped `private`, I *have* used it fruitfully on several occasions. These were typically in places where I wanted to restrict access to a small number of members which I could ensure would enforce certain invariants. An example I gave previously involved two arrays which contained matching elements; code should never insert or remove from one array without doing the same to the other. By making these arrays `private` and exposing `fileprivate` and `public` members derived from them, I could ensure that only a couple dozen lines could possibly contain such a bug without changing the external design of the type or introducing boilerplate.

This proposal does not offer the same utility. The only way to protect fragile parts of a type from other parts is to extract them into a separate type, and even then, you can extend that new type anywhere in the file to access the fragile parts. You're also likely to end up having members on the outer type which simply call into equivalent members on the inner type. It increases boilerplate and reduces protection.

Despite having used scoped `private` in the past, if the choice were between keeping it and giving it `fileprivate` semantics, I would still support the latter; I think the simplification would be worth the loss of tight encapsulation. But this proposal offers *neither* simplification *nor* tight encapsulation, so I'm opposed to it.

-- 
Brent Royal-Gordon
Architechies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170406/017534bd/attachment.html>