> I’ve seen a number of concerns on this list about moduleprivate, and how it > penalizes folks who want to explicitly write their access control. I’ve come > to think that there is yes-another possible path forward here (which I > haven’t seen mentioned so far): > > public > internal > fileprivate > private
I don't like how this ends up penalizing `fileprivate` with an ugly compound keyword. I feel like, with the way I tend to factor my code, I would continue using it reasonably often, and it would suck to have to use an ugly keyword. Consider some of the places where we're still going to need `fileprivate`: * Members used by operators or other free functions. * Members of nested types meant to be used only by the containing type. * Code which splits a type up into extensions. (We want to encourage this.) * Code which pairs a type with an extension adding an API using that type to another type. (We want to encourage this too.) These are all things we want to encourage, and things where just making them `internal` is going to be tempting. Access control is a delicate thing; using tight access control imposes obvious short-term costs for subtle long-term gains, and so you're always tempted to cheat by making things broader than they should be for your own convenience. The only thing keeping you from cheating is your own discipline. I worry that, if `fileprivate` is a long, ugly, obscure, and cumbersome keyword, and `internal` works just as well but requires no typing at all, a lot of people are going to do the wrong thing. We don't want that to happen. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
