How about making things more organized and move to syntax like this: private(scope) decl
Where scope is optional and defaults to full private. Can take "file" and "type" values. I.e: private (file) var i = 1 private func a() private (type) func b() This way we can have a very fine grained access levels and maintain a better structure. Who knows maybe in Swift 5 there will be need for more. On Thu, 1 Dec 2016 at 12:08 Álvaro Monteiro via swift-evolution < [email protected]> wrote: > 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 protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > 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
