This proposal is definitely *not* what I want from a submodule system, because it will exacerbate the problem of developers stuffing large amounts of code into a single file.<div><br></div><div>The “fileprivate” keyword already encourages long files, because there is no way to split up related components into separate files while retaining encapsulation. And scope-based “private” is even worse of an offender, because it requires nesting code inside the same *type declaration*, so you can’t even benefit from extensions.</div><div><br></div>To my mind, any submodule system for Swift should be designed to relieve the pressure for long files, and make it easy to group tightly related files into a single unit with shared visibility. That way developers can easily organize their code into smaller files while utilizing Swift’s pattern of providing protocol conformances in extensions and keeping implementation details hidden from the rest of the module at large.<div><br></div>For example, one possible design would enable us to replace both “private” and “fileprivate” with a single new access level—probably spelled “private— which restricts visibility to just the current submodule. That way it provides all the benefits of “fileprivate” (implementation hiding and the ability to use extensions) while also allowing code to be placed in separate files rather than one large file.<div><br></div><div>Nevin</div>