@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 <
> 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.
> swift-evolution mailing list
swift-evolution mailing list