[swift-evolution] [Proposal][Discussion] Modular Swift

Nevin Brackett-Rozinsky nevin.brackettrozinsky at gmail.com
Tue Feb 21 18:36:37 CST 2017

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.

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.

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.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170221/c6fef05f/attachment.html>

More information about the swift-evolution mailing list