*@Daniel* I am very fond of your idea, as I believe it add extra flexibility to this solution, as Álvaro mentioned. My only concern is somehow related to semantics. Should we add the extra scope detail as you suggest, then it could clash with the current way of setting a setter as private or fileprivate:
Current: fileprivate(set) Suggested: private(file)(set) Still, of all the hurdles one might face, this one I believe is definitely the one that poses the less threat! *@Tino* As you imply on a previous email, this solution might even facilitate the introduction of new levels of access control all throughout modules, whether internally and externally. While I do agree complexity does raise an issue in designing a fine solution for access control, I insist this concern should not block the language's evolution into finer grained control and better focused levels of scope. Quoting Álvaro: "communication is something that everyone agrees is a essential in swift and access control is one of the many ways developers have to properly describe (and communicate) an API." Also Tino, you state: "The question for me is how much complexity should be accepted as a tradeoff for increased expressiveness? "private, internal, public" was quite simple, but the current system is already quite complicated, and it doesn't scale well." In fact, I consider this change a great opportunity for the current system to be revisited in a gradual manner. As to the equatable issue you pointed out, is there a reason why replacing the fileprivate access control level by with a typeprivate would not solve the problem raised with private? There's yet another issue I would like to reinforce, one raised on previous emails. As stated before, I do believe fileprivate, as a compiler related construct, opens the door for one to access members from another member, as long as they'r all sitting within the same file. This creates conditions for a odd and dangerous pattern. While I don't think fileprivate aims at promoting several type implementation within the same file, it certainly opens that door. That's one pattern a typeprivate access control level would grant no advantages in using. Best, Gonçalo
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
