This still gives headaches to me: > If everything reachable is also visible then changing the set of imported > modules is always a breaking change for any "downstream" modules since they > can all name things from those modules without actually importing them. It > also greatly increases the risk of name collision.
What is the argument here? Is i a pro or con argument? Then... > Yes, there is an abstraction barrier between them, and that's what modules > let you write. Without modules Notvisible would be usable in the same ways as > Visible and would have to be if you ever wanted to use Visible. There's a > dependency between the types no matter what, since the compiler needs to know > NotVisible's size. If there is an abstraction barrier, the compiler must NOT know NotVisible's size. Therefore, only pointers could be used. But NotVisible could be imported as a restricted type, as a constrained stable supertype providing limited access to the type, e.g. its size. Swift has `opaque` types allowing for very dynamic bindings. In prinicple, `alloca` could be used to pack such a thing on the stack at runtime. Then, move semantics will take place to move/pass the object around, copies and refcount updates included.
