I think entities declared as “internal” should be visible throughout the entire *module* just as they are today. In particular, if I write “struct Foo {}” inside a submodule, then Foo should have internal visibility (the default when no access level is specified) and thus should be available to the entire module.<div><br></div><div>Similarly, if I write “public struct Bar {}” inside a submodule, then Bar should be exported from the module and available to client code. In other words, the submodule should exist to *organize* code, not to change its meaning.<div><br></div><div>Moreover, the ongoing access level discussions elsewhere on the list make clear that many people believe there should be just one visibility more restricted than “internal” (which of course should be named “private”). If we go that route, then “private” would mean “visible in this submodule only”. For files which are not in a submodule this acts like “fileprivate”, and for files which *are* in a submodule it means they can share their implementation details with closely related code (usually types and extensions) while allowing that code to be in separate files as appropriate.</div><div><br></div><div>That is most of what I want out of submodules: to provide all the benefits of Swift-2-era “private” without requiring that everything be stuffed inside one single file. For all other purposes a submodule would be transparent, it just lets you split up a large file along its natural divisions. Consequently, I see no need or purpose for nested submodules, because a submodule simply “acts like” a single file.</div><div><br></div><div>Nevin</div></div>