Implement Alvarez & Monteiro's "typeprivate", possibly with one or two extra restrictions

It is the very arbitrary-ness of a file that makes it such a good way to define an access control boundary.

The problem with something like typeprivate is that, if the enclosing type doesn’t quite encompass the code that ought to have access to the declaration, you either need to move declarations into/out of the type to grant/restrict access, or you need to abandon typeprivate. If you do the former, you’re contorting the design of your types to fit into the access control system, which can have some unfortunate knock-on effects. If you do the latter, then the feature is useless to you.

Files don’t have that problem—other than access control (and the tautological purpose of #file and friends), they don’t have any other function. They’re vaguely used for code organization, but you usually want one file per “concern” or “function”, which is basically where you want access control boundaries anyway. The result is a feature that’s almost as flexible as C++ friend, but way less complicated.

So it’s precisely the fact that files are an arbitrary boundary that makes them good for access control. An arbitrary boundary is one you can draw around whatever you want—and that’s perfect for access control.

11 Likes