> On 3 Apr 2017, at 23:55, Brent Royal-Gordon <[email protected]> wrote: > >> On Apr 3, 2017, at 2:19 PM, John McCall via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> Won’t making big modifications later be even more problematic than now, in >>> the name of source stability? >> >> Yes. Big changes along these lines will not be considered later. At best, >> it would be possible to "re-cast" existing behaviors in light of new >> features — that is, significantly changing *how we talk about those >> behaviors*, and changing how we understand them in the broader language, but >> not actually changing the behaviors themselves. > > 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). And it would still allow many uses of private, like Drew Crawford’s ThreadsafeWrapper example from the 23rd of March. > 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. > (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. > So let's leave access control alone for now exactly as it is (including the > "no duplicates" implementation limit), come up with a > stored-properties-in-extensions strategy for Swift 5, and evaluate loosening > `private` in a source-compatible way once we know what the experience will be > like in the long run. > > -- > Brent Royal-Gordon > Architechies >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
