<div dir="ltr">On Tue, Feb 21, 2017 at 8:22 PM, Robert Widmann <span dir="ltr">&lt;<a href="mailto:devteam.codafi@gmail.com" target="_blank">devteam.codafi@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Feb 21, 2017, at 9:13 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="m_-8007862380282272968Apple-interchange-newline"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution<span class="m_-8007862380282272968Apple-converted-space"> </span><span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-<wbr>evolution@swift.org</a>&gt;</span><span class="m_-8007862380282272968Apple-converted-space"> </span>wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><span><div>On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div></span><span><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></div></span></blockquote><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>It&#39;s supported, but it isn&#39;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&#39;ll touch on is supporting both with the same syntax. The chief drawbacks here are:</div><div><br></div></div></div></div></div></blockquote><div><br></div></span><div>What exactly would be required to <i>make</i> it first class?  Referencing file names in the module declaration?</div></div></div></blockquote><div><br></div><div> See below.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div>- 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.</div><div><br></div></div></div></div></div></blockquote><div><br></div></span><div>If braces aren’t used to demarcate scopes, nesting modules becomes ambiguous.</div></div></div></blockquote><div><br></div><div>Again, let&#39;s observe the distinction about grouping files vs. grouping lines.</div><div><br></div><div>Grouping files does not require braces: if the intended use of your feature were to label files X, Y, and Z as belonging to one submodule and A, B, and C to another, it would not matter if X, Y, and Z belonged to Foo.Bar and A, B, and C to Foo.Bar.Baz: your syntax would not require braces.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>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 &quot;fix this&quot; at the time when a proposal to “flatten” these declaration was brought up.</div></div></div></blockquote><div> </div><div>Mine is not a critique of the syntax itself; I don&#39;t particularly care about indents, nor do I mind not indenting namespaces.</div><div><br></div><div>What I&#39;m saying is, you would not have chosen to require braces if your proposed feature were aimed at making the grouping of files into submodules as simple as possible. You chose to accommodate grouping lines using the same syntax as grouping files over the simplest design for grouping files. Make no mistake, this promotes one use over another.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div>- 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.</div></div></div></div></div></blockquote><div><br></div></span><div>Absolutely.  But it is similarly arbitrary which public APIs are exposed in a type declaration and which are exposed in an extension declaration.</div></div></div></blockquote><div><br></div><div>Not entirely, no. Stored properties must be in the type declaration. Enum cases must be in the type declaration. Perhaps you regard these as temporary inconveniences of the current grammar; I see them as quite reasonable ways to give some consistency as to what&#39;s written where in a language where types can be retroactively extended. In a very real sense, you must read the type declaration before you read the extensions in order to understand the latter. By comparison, there is nothing that must be in your proposed module declaration.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>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.</div></div></div></blockquote><div><br></div><div>Indeed, that you phrase it this way supports Nevin&#39;s argument. _Module extensions_ exist to accommodate his use case; however, his use case (which, mind you, is what I think most people are thinking of when it comes to submodules, given previous threads on this topic) isn&#39;t the raison d&#39;etre for your submodule proposal. Quite simply, a syntax that accommodates both grouping lines and grouping files cannot make the latter first class, because the former necessarily requires more ceremony.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div class="h5"><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>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:</div><div><br></div><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,132,0)"><span style="font-variant-ligatures:no-common-ligatures">// FooUtilities.swift</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,132,0)"><span style="font-variant-ligatures:no-common-ligatures">//</span></div><span><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,132,0)"><span style="font-variant-ligatures:no-common-ligatures">// -module-name=Foo</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,132,0)"><span style="font-variant-ligatures:no-common-ligatures">// module Foo {</span></div></span><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,132,0)"><span style="font-variant-ligatures:no-common-ligatures">// Defines Foo.Utilities</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">module Utilities {</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"> <span class="m_-8007862380282272968Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)">public</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8007862380282272968Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)">func</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8007862380282272968Apple-converted-space"> </span>exportableOutsid<wbr>eThisSubmodule() {}</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"> <span class="m_-8007862380282272968Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)">func</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8007862380282272968Apple-converted-space"> </span>visibleInThisSubmodule(<wbr>) {}</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"> <span class="m_-8007862380282272968Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)">private</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8007862380282272968Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)">func</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8007862380282272968Apple-converted-space"> </span>invisibleToOthe<wbr>rFiles() {}</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">}</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,132,0)"><span style="font-variant-ligatures:no-common-ligatures">//}</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;min-height:13px"><span style="font-variant-ligatures:no-common-ligatures"></span><br></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,132,0)"><span style="font-variant-ligatures:no-common-ligatures">// FooUtilities+MoreUtilities.swi<wbr>ft</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(186,45,162)"><span style="font-variant-ligatures:no-common-ligatures">extension</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8007862380282272968Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)">Utilities</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8007862380282272968Apple-converted-space"> </span>{</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"> <span class="m_-8007862380282272968Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)">private</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8007862380282272968Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)">func</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8007862380282272968Apple-converted-space"> </span>privateHelper() {</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(49,89,93)"><span style="font-variant-ligatures:no-common-ligatures">   <span class="m_-8007862380282272968Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures">visibleInThisSubmodule</span><span style="font-variant-ligatures:no-common-ligatures">()</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"> <span class="m_-8007862380282272968Apple-converted-space"> </span>}</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">}</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><br></span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">I’m not sure where you got the impression that we were just trying to make another fileprivate happen.</span></div></div><br><blockquote type="cite"><div><div><br></div><div>Nevin</div><span>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br></span></div></blockquote></div><br></div><br>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a></blockquote></div></div></div></div></blockquote></div></div></div><br></div></blockquote></div><br></div></div>