[swift-evolution] [Pitch] Let's talk about submodules

[Nevin Brackett-Rozinsky]

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.

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.

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.

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.

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