> On Apr 7, 2017, at 12:56 AM, Jean-Daniel <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
