> Le 7 avr. 2017 à 03:53, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> a écrit : > >> On Apr 6, 2017, at 5:38 PM, Charles Srstka via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@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.
What about using 2 files ? One for private fragile part, one for ‘public’ part. > 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 > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
