<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=""><div class=""><blockquote type="cite" class=""><div class="">On 19 Jul 2016, at 00:09, Robert Widmann via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">TJ Usiyan, Harlan Haskins, and I have been working on a proposal to rework qualified imports and introduce an explicit module system to Swift that we’d like to publish for your viewing pleasure.</div><div class=""><br class=""></div><div class="">The initial impetus was set out in a radar (<a href="rdar://17630570" class="">rdar://17630570</a>) I sent fairly early on that didn’t receive a response, so I started a <a href="http://permalink.gmane.org/gmane.comp.lang.swift.evolution/1378" class="">swift-evolution</a> thread discussing the basics of this proposal. It has been refined and expanded a bit to include an effort to make Swift modules explicit and updated with the feedback of that first thread. Contents of the proposal are inline and <a href="https://gist.github.com/CodaFi/42e5e5e94d857547abc381d9a9d0afd6" class="">can also be had as a gist</a> or <a href="https://github.com/apple/swift-evolution/pull/440" class="">on Github.</a></div></div></div></blockquote></div><div class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""></div></div></div><div class="">Firstly, thank you Robert, TJ, and Harlan for the proposal and especially for considering the introduction of submodules too! Those would be very useful when Swift libraries start growing. But maybe we can delay that discussion past Swift 3.</div><div class=""><br class=""></div><div class="">* * *</div><div class=""><br class=""></div><div class="">Secondly, I used to be in the selective import camp before, but I think it's somewhat counter to Swift's feel and direction where most of the API is wrapped inside types, and function names consist of not just the base name but argument labels too (even if we now have the "Gregorian" naming SE-0021 available). So while I don't see a big problem introducing something like</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""> <b class="">import</b> Foo.(fooConstant, bar(a:b) <b class="">as</b> bar1(a:b:), IrrelevantType <b class="">as</b> _)</font></div><div class=""><br class=""></div><div class="">to pick identifiers à la carte, I don't think it would be useful very often. And the alternative of accessing `<font face="Menlo" class="">bar</font>` through the module name as `<font face="Menlo" class="">Foo.bar</font>` does work just as well already.</div><div class=""><br class=""></div><div class="">…Well, that is except for the problem when the module name `<font face="Menlo" class="">Foo</font>` happens to be <b class="">shadowed</b> by a <i class="">non-module</i> name `<font face="Menlo" class="">Foo</font>`. I'd rather tackle that problem, and I do so as follows:</div><div class=""><br class=""></div><div class="">* * *</div><div class=""><br class=""></div><div class="">My usual pain points with imported (micro-)frameworks have been:</div><div class=""><br class=""></div><div class="">A) …when two modules (e.g. `<font face="Menlo" class="">Foo</font>` and `<font face="Menlo" class="">Bar</font>`) export the same identifier (`<font face="Menlo" class="">baz</font>`) for different meanings.</div><div class="">B) …when a local or imported identifier (e.g. `<font face="Menlo" class=""><b class="">class</b> Tree</font>`) has the same name as a module `<font face="Menlo" class="">Tree</font>`.</div><div class=""><br class=""></div><div class="">In case A, I can just disambiguate by prefixing with the module name: `<font face="Menlo" class="">Foo.baz</font>` vs. `<font face="Menlo" class="">Bar.baz</font>`.</div><div class=""><br class=""></div><div class="">In case B, there is really no way around that I'm aware of. Anyway you write `<font face="Menlo" class="">Tree.foo</font>` Swift will try to look up under the type `<font face="Menlo" class="">Tree</font>` and never the module `<font face="Menlo" class="">Tree</font>`.</div><div class=""><br class=""></div><div class="">Those two issues could be addressed by simply introducing <i class="">qualified</i> imports as follows:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""> <b class="">import</b> Darwin <b class="">as</b> Darwin <font color="#919191" class="">// qualified import (there could be a shorthand but what?)</font></font></div><div class=""><font face="Menlo" class=""> <b class="">import</b> UIKit <b class="">as</b> UI <font color="#919191" class="">// qualified import with renaming</font></font></div><div class=""><font face="Menlo" class=""> <b class="">import</b> Tree <font color="#919191" class="">// unqualified import brings in struct Tree.Tree, among others.</font></font></div><div class=""><font face="Menlo" class=""> <b class="">import</b> Tree <b class="">as</b> T <font color="#919191" class="">// qualified import</font></font></div><div class=""><span style="font-family: Menlo;" class=""> </span></div><div class=""><font face="Menlo" class=""> <b class="">let</b> out = Darwin.stdout <font color="#919191" class="">// ok</font></font></div><div class=""><div class=""><font face="Menlo" class=""> <b class="">var</b> vc: UI.UIViewController? <font color="#919191" class="">// ok</font></font></div></div><div class=""><div class=""><span style="font-family: Menlo;" class=""> </span><b style="font-family: Menlo;" class="">let</b><span style="font-family: Menlo;" class=""> tree: Tree = T.emptyTree </span><font color="#919191" style="font-family: Menlo;" class="">// ok; `struct Tree.Tree` was imported unqualified</font></div></div><div class=""><font color="#919191" style="font-family: Menlo;" class=""> </font></div><div class=""><font face="Menlo" class=""> <b class="">let</b> err = <font color="#ff2600" class="">stderr</font></font></div><div class=""><font face="Menlo" class=""> <font color="#919191" class="">// <b class="">error:</b> Use of unresolved identifier 'stderr'</font></font></div><div class=""><font face="Menlo" class=""> <font color="#919191" class="">// <b class="">note:</b> did you mean 'Darwin.stderr'?</font></font></div><div class=""><font face="Menlo" class=""> </font></div><div class=""><span style="font-family: Menlo;" class=""> </span><b style="font-family: Menlo;" class="">var</b><span style="font-family: Menlo;" class=""> view: </span><font color="#ff2600" style="font-family: Menlo;" class="">UIView</font><span style="font-family: Menlo;" class="">?</span></div><div class=""><font face="Menlo" class=""> <font color="#919191" class="">// <b class="">error:</b> Use of unresolved type 'UIView'</font></font></div><div class=""><font face="Menlo" class=""> <font color="#919191" class="">// <b class="">note:</b> did you mean 'UI.UIView'?</font></font></div><div class=""><font face="Menlo" class=""> </font></div><div class=""><font face="Menlo" class=""> <b class="">enum</b> <font color="#ff2600" class="">UI</font> {}</font></div><div class=""><font face="Menlo" class=""> <font color="#919191" class="">// <b class="">error:</b> invalid redeclaration of 'UI'</font></font></div><div class=""><font face="Menlo" class=""> <font color="#919191" class="">// <b class="">note:</b> 'UI' previously declared (line 2)</font></font></div><div class=""><br class=""></div><div class="">The qualified import syntax, `<font face="Menlo" class=""><b class="">import</b> MODULE <b class="">as</b> NAME</font>`, imports the module <font face="Menlo" class="">MODULE</font> such that its contents can be accessed through the prefix of `<font face="Menlo" class="">NAME.</font>` – but not without it, unless also imported without qualification.</div><div class=""><br class=""></div><div class="">The given <font face="Menlo" class="">NAME</font> uses up that identifier in the current scope (as if it was a private type) such that there can be no locally visible type or value with the same name in that scope. For example, if the current module defined <font face="Menlo" class="">NAME</font> <i class="">publicly</i> or <i class="">internally</i> in another file, then that identifier would be shadowed in this file by the qualified module name <font face="Menlo" class="">NAME</font>.</div></div><div class=""><br class=""></div><div class="">Side note: It is still possible to chain multiple module imports, qualified or not, on the same line (albeit not a particularly good coding style if they're unrelated). The order of imports does not matter. So the above example could've been written as:</div><div class=""><br class=""></div><div class=""><span style="font-family: Menlo;" class=""> </span><b style="font-family: Menlo;" class="">import</b><span style="font-family: Menlo;" class=""> Darwin </span><b style="font-family: Menlo;" class="">as</b><span style="font-family: Menlo;" class=""> Darwin, UIKit <b class="">as</b> UI, Tree <b class="">as</b> T, Tree</span></div><div class=""><br class=""></div><div class="">* * *</div><div class=""><br class=""></div><div class="">I think that's the small change we need most urgently. The rest can wait.</div><div class=""><br class=""></div><div class="">— Pyry</div><div class=""><br class=""></div><div class="">PS: Another thing I'd see useful, especially when migrating code from the `<font face="Menlo" class="">MyPlayground_Sources</font>` module to a real project would be a syntax something like `<font face="Menlo" class="">_.foo</font>` to access the `<font face="Menlo" class="">foo</font>` that is visible in the current file top-level, so to escape any local shadowing.</div><br class=""></body></html>