-1. If an API designer wants to allow access to a “hidden’ member, he should be in control of that access. The proposed chance simply opens up access completely and leads to API vulnerability.
(I am in favour of a “friend” solution, in which the API designer explicitly allows access to identified members of the API users.) Rien. > On 16 Oct 2016, at 22:34, Jonathan Hull via swift-evolution > <[email protected]> wrote: > > I keep wanting a “protected” access level, but I must also admit that there > was something really elegant about Swift 2’s access scheme (and I think most > of us feel like the word ‘fileprivate’ feels out of place). I was thinking > about how to mesh those two ideas, and I think I may have come up with a > solution. > > I propose we replace ‘fileprivate’ with a new ‘hidden’ access level. Hidden > would work exactly the same way as fileprivate does now, but adds the > connotation that what is hidden can also be unhidden. By adding ‘import > hidden TypeName’ to another file, that file also gains access to all of the > hidden items of that type (kind of like if it was in the same file). > > #FileA > import Foundation > > Struct A { > private var x:Int > hidden var y:Int //This is just like fileprivate, but can also > be shared with other files > } > > extension A { > //y can be accessed here because they are in the same file > } > > > #FileB > import Foundation > import hidden A //This allows the entire file to see A’s hidden > variables > > extension A { > //y can be accessed here because of the ‘import hidden’ > declaration > } > > > #FileC > import Foundation > > extension A { > //y can NOT be seen or accessed here because it is hidden > } > > > I think this is a fairly elegant solution to our protected dilemma, which > also feels in sync with Swift 2’s file-based scheme. The key features: > • Extensions no longer need to be piled in the same file if it is > getting too long > • Subclasses can be in their own file, but still have access to the > necessary parts of their superclass > • It communicates the author’s intent that the items are not meant to > be visible to its users, but that it is expected to be used for > extension/subclassing > • It requires an explicit statement ‘import hidden’ to access the > hidden variables. Safe by default, with override. > • It is not bound by module boundaries (i.e. you could use it for > subclassing classes from an imported module) > • Roughly the same length as ‘private’ and ‘public’ so various > declarations packed together are much easier to read (fileprivate breaks > reading rhythm) > > Worth a formal proposal? > > Thanks, > Jon > > > > _______________________________________________ > 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
