[swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions
brent at architechies.com
Fri Apr 7 02:59:55 CDT 2017
> 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution