If not interfile I can suggest infile again too. > On Mar 31, 2016, at 12:38 AM, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > >> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
