<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Then let’s discuss that.</div><div class=""><br class=""></div><div class="">You claim Swift has some emphasis on file-oriented programming constructs, I argue this is the case locally (fileprivate), but not the case in the language as a whole. Looking more broadly, it is possible to restrict yourself to a particular view where one public type resides in one file, but then what to make of extensions? What becomes of “internal” access, which permeates the entire module crossing over any file boundaries that might exist? Today, a Swift module can depend on the kinds of files given to the compiler, but there is particular emphasis on a module not necessarily being a collection of files, but a collection of interfaces all living under the same shared namespace (the module name). A particular facet of that interface set may be freely extended by the presence, or contracted by the absence, of a file or files when the module is built but one could very well imagine alternative abstractions that would serve this purpose just as well - e.g. an in-memory AST.</div><div class=""><br class=""></div><div class="">Maybe what you notice is that you are encouraged (or rather, required) by your <i class="">tools</i> to organize your code a particular way, and this is no mistake. They exist apart from the language itself for a reason, because they themselves often depend on the state of the filesystem or the outside world and that concern spills over (correctly or not) into your organizational style. But organizational style is just that: we can enable a broader class of programs to be designed with the system given here than with one that restricts us to a subset of it. Because let’s not forget, it is actually a subset of the functionality presented herein. If the proposal’s were implemented today, you would absolutely be able to design these kinds of modules and tie them to filesystem locations. But you would also be free to group functionality and tie a set of files together into the same (sub)module.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 21, 2017, at 10:46 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Well put. As for me, it is not the syntactic delta with which I am concerned. It is just a canary for the organizational delta.<br class=""><br class="">There are certain freedoms enabled not by the _lack_ of constraints but rather their judicious application. Swift has in the past--and it is your burden to justify why it shouldn't continue to in the future--judged the file-based approach to be one such judicious constraint.<br class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Feb 21, 2017 at 21:42 Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:<br class=""></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" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Feb 21, 2017, at 10:36 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="gmail_msg" target="_blank">matthew@anandabits.com</a>> wrote:</div><br class="m_2680087035137354333Apple-interchange-newline gmail_msg"><div class="gmail_msg"><blockquote type="cite" 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" class="gmail_msg"><div class="gmail_msg"><br class="m_2680087035137354333Apple-interchange-newline gmail_msg">On Feb 21, 2017, at 9:28 PM, Robert Widmann via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_2680087035137354333Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div 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" class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><br class="m_2680087035137354333Apple-interchange-newline gmail_msg">On Feb 21, 2017, at 10:03 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_2680087035137354333Apple-interchange-newline gmail_msg"><div class="gmail_msg"><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" class="gmail_msg">On Tue, Feb 21, 2017 at 8:41 PM, Robert Widmann<span class="gmail_msg m_2680087035137354333Apple-converted-space"> </span><span dir="ltr" class="gmail_msg"><<a href="mailto:devteam.codafi@gmail.com" class="gmail_msg" target="_blank">devteam.codafi@gmail.com</a>></span>wrote:<br class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><span class="m_2680087035137354333gmail- gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Feb 21, 2017, at 9:37 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="gmail_msg m_2680087035137354333gmail-m_5120989393589330941Apple-interchange-newline"><div class="gmail_msg"><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" class="gmail_msg">On Tue, Feb 21, 2017 at 8:22 PM, Robert Widmann<span class="gmail_msg m_2680087035137354333gmail-m_5120989393589330941Apple-converted-space"> </span><span dir="ltr" class="gmail_msg"><<a href="mailto:devteam.codafi@gmail.com" class="gmail_msg" target="_blank">devteam.codafi@gmail.com</a>></span>wrote:<br class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" 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" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Feb 21, 2017, at 9:13 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="gmail_msg m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-interchange-newline"><div class="gmail_msg"><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" class="gmail_msg">On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution<span class="m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-converted-space gmail_msg"> </span><span dir="ltr" class="gmail_msg"><<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>></span><span class="m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-converted-space gmail_msg"> </span>wrote:<br class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" 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" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><span class="gmail_msg"><div class="gmail_msg">On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div></span><span class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></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 class="gmail_msg"><br class="gmail_msg"></div></div></span></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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:</div><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">What exactly would be required to<span class="gmail_msg m_2680087035137354333gmail-m_5120989393589330941Apple-converted-space"> </span><i class="gmail_msg">make</i><span class="gmail_msg m_2680087035137354333gmail-m_5120989393589330941Apple-converted-space"> </span>it first class? Referencing file names in the module declaration?</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> See below.</div><blockquote class="gmail_quote gmail_msg" 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" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><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" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">- 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 class="gmail_msg"><br class="gmail_msg"></div></div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">If braces aren’t used to demarcate scopes, nesting modules becomes ambiguous.</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Again, let's observe the distinction about grouping files vs. grouping lines.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" 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" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">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.</div></div></div></blockquote><div class="gmail_msg"> </div><div class="gmail_msg">Mine is not a critique of the syntax itself; I don't particularly care about indents, nor do I mind not indenting namespaces.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">What I'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></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span>Ah, I see. Yes, one of the stated goals is to become filesystem-independent. We certainly cannot do that by encouraging the alternative.</div></div></blockquote><div class="gmail_msg"> </div><div class="gmail_msg">Swift's current design is deliberately not file system-independent. A submodule design built on top of Swift could preserve that. Your draft proposal makes two changes: it introduces a design for submodules; and, it eliminates files as a unit of code by default (not least by declaring `fileprivate` redundant). To my mind, you have presented no justification for the second change other than to say that it is a stated goal--but why?<br class="gmail_msg"></div></div></div></div></div></blockquote><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255);margin-bottom:0px!important" class="gmail_msg"><li style="box-sizing:border-box" class="gmail_msg"><code style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="gmail_msg">fileprivate</code> access can be recreated by creating a private "utility submodule" containing declarations of at most <code style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="gmail_msg">internal</code> access.</li></ul><div class="gmail_msg"><br class="gmail_msg"></div></div><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><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" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><span class="m_2680087035137354333gmail- gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><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" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" 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" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><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" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">- 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 class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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'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 class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" 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" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Indeed, that you phrase it this way supports Nevin'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't the raison d'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 class="gmail_msg"><br class="gmail_msg"></div></div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">Okay, but the question still stands: what do we need to make Nevin's use-case first class?</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">We need to have either *two* spellings for a submodule feature that supports both grouping files and grouping lines of code, or we need to have *two* features, one for grouping files and another for grouping lines of code. In any case, the spelling for grouping files should:</div><div class="gmail_msg">- Not require braces</div><div class="gmail_msg">- Not require one file to be a `module` and another to be an `extension`</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The simplest such spelling would be:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">File A:</div><div class="gmail_msg">```</div><div class="gmail_msg">module Foo</div><div class="gmail_msg">// rest of file</div><div class="gmail_msg">```</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">File B:</div><div class="gmail_msg">```</div><div class="gmail_msg">module Foo</div><div class="gmail_msg">// rest of file</div><div class="gmail_msg">```</div></div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This was mentioned earlier, so I will quote my response to the last poster:</div><div class="gmail_msg"><br class="gmail_msg"></div></div><blockquote 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;margin:0px 0px 0px 40px;border:none;padding:0px" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">That is a valid spelling (Rust, IIRC, allows that spelling), but one that is easy to miss sitting in a file and makes it confusing to introduce submodules. If you include the annotation then define a submodule later down in the file, suddenly you have to remember whether you annotated the file or whether the submodule you’ve just written is going into the top-level module. See:</div></div><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">// -module-name=Foo</div></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">// module Foo {</div></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">module Bar; // Shorthand for “This file defines Foo.Bar”</div></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">/* Code */</div></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">// This defines “Foo.Bar.Baz”, but would you know that if it appeared below the fold?</div></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">module Baz {}</div></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">//}</div></div></div></blockquote><div 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" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div></div><div class="gmail_msg">But that reply was oriented towards a “why can’t we have nested modules and a shorthand too?” Here, you’re referring more to the one-module-one-file language restrictions, so I will quote another response:</div><div class="gmail_msg"><br class="gmail_msg"></div></div><blockquote 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;margin:0px 0px 0px 40px;border:none;padding:0px" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">For one-file-per-module, that kind of restriction represents a particular way of organizing code and is a design pattern that is supported under this proposal. We just happen to not enforce that particular pattern, and feel that it is the job of a linter to do so. Really, this kind of restriction is to ease the mental burden on compiler writers who use it to build compilation unit dependency graphs. Swift already considers all files when building its modules because you can extend any type (and now, any module) from any one of them so it doesn’t buy us anything other than an arbitrary restriction.</div></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div></div></div></blockquote><div 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" class="gmail_msg">Realistically, the only difference between the proposal’s syntax and this one is two characters (the braces) and maybe some tabs if you decide to enforce that style. There are few objective organizational benefits from your style, and it creates a bureaucratic rule where none need exist. Subjectively, of course, people may prefer this way, or they may prefer a more ad-hoc approach. But we designed for both cases and showed our hand by favoring non-physical organization because it is a subset of possible organizational styles available to users.</div></div></blockquote><div 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" class="gmail_msg"><br class="gmail_msg"></div><div 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" class="gmail_msg">Your earlier post argues that your syntax is better because with the alternative approach it’s too easy to forget whether there is a module statement at the top of the file or not. Now you’re arguing that the difference is just two braces and that they’re relatively insignificant. You can’t have it both ways.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Now I’m context switching… I will clarify: Syntactically the delta between the proposal and Xiaodi’s syntax is two braces. Organizationally it means the difference between Java-style packages that divide named modules into files and approaches that allow for freedom by ignoring this constraint.</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div 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" class="gmail_msg"><br class="gmail_msg"></div><br 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" class="gmail_msg"><blockquote type="cite" 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" class="gmail_msg"><div class="gmail_msg"><div 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" class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><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" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">To my mind, we’ve offered a syntax and semantics internal to the language that supports file-only aggregation because file-only aggregation enables a subset of the actual use cases of this module system. We aren’t enforcing this by compiler-fiat because it is a stylistic choice that can be enforced by a linter.</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">It's not enough to offer a syntax and semantics that supports it; if it is the intended major use case, the design ought to reflect that by making that use case no less cumbersome than necessary.</div></div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">See above for aesthetic concerns.</div><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><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" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="m_2680087035137354333gmail-h5 gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><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" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" 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" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg m_2680087035137354333gmail-m_5120989393589330941h5"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><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" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" 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" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;color:rgb(0,132,0)" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">// FooUtilities.swift</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;color:rgb(0,132,0)" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">//</span></div><span class="gmail_msg"><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;color:rgb(0,132,0)" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">// -module-name=Foo</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;color:rgb(0,132,0)" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">// module Foo {</span></div></span><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;color:rgb(0,132,0)" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">// Defines Foo.Utilities</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">module Utilities {</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"> <span class="m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-converted-space gmail_msg"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)" class="gmail_msg">public</span><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"><span class="m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-converted-space gmail_msg"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)" class="gmail_msg">func</span><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"><span class="m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-converted-space gmail_msg"> </span>exportableOutsideThisSubmodule() {}</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"> <span class="m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-converted-space gmail_msg"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)" class="gmail_msg">func</span><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"><span class="m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-converted-space gmail_msg"> </span>visibleInThisSubmodule() {}</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"> <span class="m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-converted-space gmail_msg"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)" class="gmail_msg">private</span><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"><span class="m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-converted-space gmail_msg"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)" class="gmail_msg">func</span><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"><span class="m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-converted-space gmail_msg"> </span>invisibleToOtherFiles() {}</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">}</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;color:rgb(0,132,0)" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">//}</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;min-height:13px" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"></span><br class="gmail_msg"></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;color:rgb(0,132,0)" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">// FooUtilities+MoreUtilities.swift</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;color:rgb(186,45,162)" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">extension</span><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"><span class="m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-converted-space gmail_msg"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)" class="gmail_msg">Utilities</span><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"><span class="m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-converted-space gmail_msg"> </span>{</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"> <span class="m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-converted-space gmail_msg"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)" class="gmail_msg">private</span><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"><span class="m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-converted-space gmail_msg"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)" class="gmail_msg">func</span><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"><span class="m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-converted-space gmail_msg"> </span>privateHelper() {</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;color:rgb(49,89,93)" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"> <span class="m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-converted-space gmail_msg"> </span></span><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">visibleInThisSubmodule</span><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">()</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"> <span class="m_2680087035137354333gmail-m_5120989393589330941m_-8007862380282272968Apple-converted-space gmail_msg"> </span>}</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">}</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"><br class="gmail_msg"></span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">I’m not sure where you got the impression that we were just trying to make another fileprivate happen.</span></div></div><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Nevin</div><span class="gmail_msg">_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></span></div></blockquote></div><br class="gmail_msg"></div><br class="gmail_msg">_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote></div><br 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" class="gmail_msg"><span 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;float:none;display:inline!important" class="gmail_msg">_______________________________________________</span><br 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" class="gmail_msg"><span 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;float:none;display:inline!important" class="gmail_msg">swift-evolution mailing list</span><br 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" class="gmail_msg"><span 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;float:none;display:inline!important" class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a></span><br 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" class="gmail_msg"><span 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;float:none;display:inline!important" class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span></div></blockquote></div></blockquote></div></div></blockquote></div>
</div></blockquote></div><br class=""></body></html>