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

[Xiaodi Wu]

On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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.
>
>
> Wonderful, because that’s absolutely supported by this proposal.  To group
> tightly related files into a single unit, simply declare a submodule for
> them and extend it in each of your related files.
>

It's supported, but it isn't first-class. By this I mean: there are two
distinguishable uses supported by your proposal, lumped together by the
fact that they are both about grouping units of code together. Put crudely,
one use case is grouping lines of code, while the other is about grouping
files of code. The merits of supporting both have already been debated in
this discussion. The issue I'll touch on is supporting both with the same
syntax. The chief drawbacks here are:

- It makes sense to use braces to group lines of code, but it makes no
sense to use braces to group files of code; this just causes entire files
to be indented.

- Because some lines of code necessarily precede some other lines of code,
it makes sense to declare the first group using `module` and to extend that
with the second group using `extension`. However, because a file of code
does not necessarily precede another file of code, it is arbitrary which
file is surrounded with a `module` declaration and which one is surrounded
with an `extension` declaration.

In both of these cases, your proposal has chosen to accommodate grouping
lines of code over the ergonomics of grouping files of code. Therefore,
while Nevin's use case is "absolutely supported by this proposal," I agree
with him that your choices promote something else entirely.


Any variables defined with `internal` access will be visible across those
> files to those extensions and only those extensions (see the section on
> access control and modules).  Any variables declared fileprivate or private
> will, obviously, not be visible across these files.  As an example:
>
> // FooUtilities.swift
> //
> // -module-name=Foo
> // module Foo {
> // Defines Foo.Utilities
> module Utilities {
>   public func exportableOutsideThisSubmodule() {}
>   func visibleInThisSubmodule() {}
>   private func invisibleToOtherFiles() {}
> }
> //}
>
> // FooUtilities+MoreUtilities.swift
> extension Utilities {
>   private func privateHelper() {
>     visibleInThisSubmodule()
>   }
> }
>
> I’m not sure where you got the impression that we were just trying to make
> another fileprivate happen.
>
>
> Nevin
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170221/71106055/attachment.html>