> Am 04.04.2017 um 01:55 schrieb Brent Royal-Gordon via swift-evolution > <[email protected]>: > >>> On Apr 3, 2017, at 3:07 PM, David Hart <[email protected]> wrote: >>> >>> On 3 Apr 2017, at 23:55, Brent Royal-Gordon <[email protected]> wrote: >>> >>> If that's the case, I don't think we should change the definition of >>> `private` to something so unproven, and which violates our access control >>> design's principles so much, right before the deadline. We do at least know >>> that scoped `private` has some uses; we have no idea if file-and-type >>> `private` will, but we *do* know it will eliminate many of the uses we've >>> found for `private` (like ensuring that only a limited set of methods can >>> use a property with tight invariants.) >> >> It’s not necessarily unproven. It’s actually much closer to what private in >> other languages look like (with Swift extensions in the mix). > > Sure, but extensions are precisely the reason why `private` is complicated in > Swift. That's a bit like saying "we should use integer string indices because > they work just fine in languages without good Unicode support". > >> And it would still allow many uses of private, like Drew Crawford’s >> ThreadsafeWrapper example from the 23rd of March. > > That's great, but the goal is not "Don't break Drew Crawford's one example > from the review thread". The goal is "provide a set of access levels which > provide appropriate degrees of protection for many use cases". > > To talk about concrete examples, here's a SortedDictionary type I wrote: > <https://gist.github.com/brentdax/106a6a80b745bd25406ede7a6becfa30> It has a > pair of `private` properties called `_keys` and `_values`, whose indices have > to stay in sync. To enforce that invariant, it uses `private` to ensure that > only a few primitive members have direct access to the properties in > question. Changing `private` to be file-and-type-based would render that > protection useless. > > Now, I could redesign this to wrap `_keys` and `_values` plus the privileged > members in a separate type, but that type would be wholly artificial; it > would have no meaning of its own, and would exist solely to get a certain > access control behavior.
I'm not sure of that: I do not think that the type would be artificial but rather that it would be a good example of OO design where a type has a certain responsibility (here: guaranteeing that _keys and _values always stay in sync). > One effect would be that I'd have to write the `startIndex` and `endIndex` > properties twice, increasing boilerplate for no good reason. Maybe having a more useful `private` is a good reason in itself? As I understand the proposal `private` is for declaring scopes within a type (instead of over part of a type like currently), `fileprivate` is for declaring scopes over a few very closely coupled types, `internal` is for declaring scopes over many types which are coupled more loosely. So the distinction between `private` and `fileprivate` would still be useful and I tend to think that the proposed change to `private` is more useful than its current strict meaning. -Thorsten > This is one of those places where scoped `private` really *is* just what I > want, and type-and-file `private` really, really isn't. > >>> I also think that allowing stored properties in same-file/same-module >>> extensions will significantly improve the usefulness of `private` and >>> reduce the need to have a same-type-same-file `private`. Right now, the >>> fact that `private` properties can only be used from the main declaration >>> requires that all types using `private` state be stuffed into that >>> declaration. But it doesn't have to be that way, and once it is, `private` >>> won't feel quite so restrictive. >> >> I think that would not help. We would still be constantly juggling between >> private and fileprivate depending if we are trying to access a property in >> the same scope or not. When writing types as a minimal internal interface >> followed by a set of grouping and conformance extensions, you would still >> constantly bump against limitations of private and resort to fileprivate. > > I look at this the opposite way: If you do not sometimes have to switch a > `private` to `fileprivate` or vice versa, then `private` and `fileprivate` > are basically synonyms and we ought to accept SE-0159 just to simplify the > language. If, in your chosen coding style, `private` and `fileprivate` are > almost always synonyms, then it's a distinction without a difference, > cognitive load that doesn't bring any benefit. > > IMHO, the "I have to switch back and forth" argument is a good reason not to > have two different sub-file access levels because it suggests that the > distinction being made is too fine. It's not a good reason to loosen one of > the sub-file access levels so it looks more like the other, which only makes > the distinction even finer. > >>> (Besides, since we currently can't have two different `private` symbols on >>> the same type in the same file, making this change later would be >>> source-compatible except for overload resolution. We can open that box any >>> time we want, but once we do, we can't close it again.) >> >> John McCall stated this is the last opportunity to improve the status-quo: >> >> I agree. This is why we asked swift-evolution to consider this last tweak: >> it is realistically the last opportunity to do it. > > And I'm pushing back on that, because there is no technical reason I can > discern why we can't go from scoped `private` to file-and-type `private`. > Perhaps there's a social reason—the core team won't want to change access > control semantics once Swift is more stable and popular, or they think this > topic is a giant ongoing distraction and want to settle it once and for all > so they can declare it off-limits forever—but I don't think we should make a > speculative change to yet a third design right before we do that. > > Honestly, I think it's becoming increasingly clear that no access control > design will ever satisfy everybody. So let's lock down the unsatisfactory > design we know, rather than the unsatisfactory design we don't. > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
