> On Feb 21, 2017, at 9:13 PM, Xiaodi Wu <[email protected]> wrote:
>
> On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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:
>
What exactly would be required to make it first class? Referencing file names
in the module declaration?
> - 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.
>
If braces aren’t used to demarcate scopes, nesting modules becomes ambiguous.
It’s important to note that indentation is one particular style. LLVM code
style, in particular, chooses not to indent after namespace declarations. This
issue also crops up when dealing with nested type declarations, and I
distinctly remember it not being a big enough deal to "fix this" at the time
when a proposal to “flatten” these declaration was brought up.
> - 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.
Absolutely. But it is similarly arbitrary which public APIs are exposed in a
type declaration and which are exposed in an extension declaration. My hope is
that the module declaration itself will become the one-stop-shop for re-exports
and general public bookkeeping just as aggregate declarations are today.
Module extensions exist to accommodate users that wish to break related
functionality across files or into separate independent regions within the same
file for the same reasons type extensions exist.
>
> 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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
