Nestmates

[Brian Goetz]

> I think, this thread shows that JVM-language tend to struggle with visibilities one way or another. Even pre-Valhalla Java does, with nested classes. 

Indeed, this has been an irritant for a long time.  Not enough of an irritant to do anything about, until now — but now that we are pushing much harder on the boundaries of “class”, something that becomes more urgent.  

> First, I think it might make sense to share the use cases we have for nestmates in Kotlin (those that will work out):
> - same as Java: nested/inner classes
> - multi-file classes (this is how we emulate free functions that are logically direct members of a package in Kotlin)

Nestmates should handle these cases.  Essentially, we are redefining the logical “class” boundary to span multiple physical classes. 

> Now, there's one issue that does not seem entirely clear to me: does this proposal imply making nested classes truly private? It does not mention allowing ACC_PRIVATE on classes, so I'm not sure whether this was intended.
> In any case it would make sense, I think. I haven't given it much thought yet, but we could probably legalize the ACC_PRIVATE flag on classes that have a NestChild entry, and check that they are only accessed from their nestmates, right? 

We haven't thought about this too deeply, but it does seem within the spirit of the proposal.  

> (This would only work with Java's every-which-way treatment of access between the nested classes: in Kotlin, for example, nested classes can not access private members of their enclosing class, but such extra restrictions don't seem to be a security concern, because all these classes are in the same compilation unit anyway.)

Right.  For example, the rules in Java for protected are somewhat more restricted than for private, and the proposed VM rules are more permissive, but the language compiler can always enforce stricter rules.