@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 <
swift-evolution@swift.org>:

> 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
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to