@Aron, I did take a look at that document while developing the proposal. As you stated, it's a little old, however the principles of access control and their purpose remain pretty much the same.
".keep private details of a class hidden from the rest of the app .keep interna details of a framework hidden from the client app" Both these rules still get respected with the introduction of a new level of access control. *typeprivate *would not allow for member access within any other then the *type* itself. @Jay, while I do appreciate your idea, I'm afraid this proposal aims at something a lot less complex. One may argue the changes in Swift's design to accommodate it may facilitate and open door to more complex changes like the one you suggest, still I believe those changes are most welcome in the name creating a safer and easier to handle access control policy. This proposal aims only at opening access to private members to any extension over that type. 2016-12-01 17:47 GMT+00:00 Martin Waitz via swift-evolution < [email protected]>: > Hi, > > Am 2016-12-01 11:08, schrieb Álvaro Monteiro via swift-evolution: > > - Typeprivate would allow to abandon the odd fileprivate. Access level > > would be constrained to swift constructs (structs, classes and > > extensions) and not to a compiler artifact (file). > > Files are not compiler artifacts but design artifacts. > They group related stuff which was designed together and which should be > reviewed together. > > I really like `fileprivate` and how Swift currently handles access control. > > -- > Martin > _______________________________________________ > 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
