> On Apr 3, 2017, at 2:19 PM, John McCall via swift-evolution > <[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.) 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. (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.) 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
