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

[Brent Royal-Gordon]

> On Apr 7, 2017, at 12:56 AM, Jean-Daniel <mailing at xenonium.com> wrote:
> 
>> 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.
> 
> What about using 2 files ? One for private fragile part, one for ‘public’ part.

Two answers:

1. I would then have to expose the "fragile part" type, which is really an implementation detail of the other type, to the entire `internal` namespace.

2. In that scenario, I would get exactly the same amount of safety from `fileprivate`. This proposal's definition of `private` gives me nothing.

-- 
Brent Royal-Gordon
Architechies

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