I think the idea behind this proposal is quite the contrary. It is about conveying the right message through the use of an expressive access control that addresses common use cases and leaves behind fileprivate which IMHO is a C inherited way of thinking.
Let me try to be clear: - Private would work the same way as it does now: it would not be accessible through an extension. - Typeprivate would be accessible through an extension inside the module. - 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). - Typeprivate would allow to address a very common use case: separate concerns of a swift struct/class through extensions and at the same time allow accessing private properties within this class/struct. At the moment you would have to have everything in the same file (and leverage fileprivate) or use internal and let it be accessible across the module. One good argument in favor of internal in these use cases would be that a given module should only be worried about what it exposes to consumers (public) and internally it's only a concern to the developers ("producers") of the module. I disagree with this because communication is one of the core tenets of swift and stating a property is internal just because is declared in another file is bizarre, unswift, error prone and it surely does not convey the right message the developer wants. On Thu, Dec 1, 2016 at 9:31 AM, Tino Heth via swift-evolution < email@example.com> wrote: > > It also means that anybody who want to access your private var will just > have to write an extension to expose it. > > imho this is wrong thinking: > Access control is no tool to offer real "protection" — it can't stop > someone who wants to break a system. > Especially in the world of open source, it is merely an advice from the > author not to do certain things. > > _______________________________________________ > swift-evolution mailing list > firstname.lastname@example.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list email@example.com https://lists.swift.org/mailman/listinfo/swift-evolution