<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=""><blockquote type="cite" class=""><div class="">On 07 Jan 2016, at 11:59, Developer 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="">I'll admit, Agda does seem to use 'renaming' to enable notational preference first and foremost. I'm not sure of too many Swift authors who would put something like that too high on their list of concerns, so +1. Drop renaming.<br class=""></div></div></blockquote></div><div class=""><br class=""></div><div class="">I tend to also agree. One more reason <i class="">not</i> to rename imported identifiers is that it makes them less googleable at call site; there's an extra human indirection (looking up the respective import statement) before being successfully at searching with the commonly known name.</div><div class=""><br class=""></div><div class="">But is there more we could prune away from this proposal? When would you really want to hide or selectively choose any <i class="">qualified</i> imports? If qualified imports always imported all identifiers, with the restriction that they must be qualified, would there (should there) ever be conflicts with anything else imported or locally defined?</div><div class=""><br class=""></div><div class="">It seems to me we could simplify it all down to just:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><b class="">import Lib</b> // Works just like in Swift 2, qualified or not</font><span style="font-family: Menlo;" class="">.</span></div><div class=""><b style="font-family: Menlo;" class="">import Lib (Foo, bar)</b><span style="font-family: Menlo;" class=""> // Only </span><b style="font-family: Menlo;" class="">Foo</b><span style="font-family: Menlo;" class=""> and </span><b style="font-family: Menlo;" class="">bar</b><span style="font-family: Menlo;" class=""> unqualified, others like </span><b style="font-family: Menlo;" class="">Lib.qux</b><span style="font-family: Menlo;" class="">.</span></div><div class=""><b style="font-family: Menlo;" class="">import Lib ()</b><span style="font-family: Menlo;" class=""> // Everything must be qualified: </span><b style="font-family: Menlo;" class="">Lib.Foo</b><span style="font-family: Menlo;" class=""> etc.</span></div><div class=""><b style="font-family: Menlo;" class="">import Lib hiding (qux)</b><span style="font-family: Menlo;" class=""> // Everything but <b class="">baz</b> works unqualified</span><span style="font-family: Menlo;" class="">, and all like </span><b style="font-family: Menlo;" class="">Lib.qux</b><span style="font-family: Menlo;" class="">.</span></div><div class=""><font face="Menlo" class=""><b class="">import Lib as L</b> // Import all unqualified, allow qualification under <b class="">L</b> like <b class="">L.Foo</b></font><span style="font-family: Menlo;" class="">.</span></div><div class=""><font face="Menlo" class=""><b class="">import Lib as L (Foo)</b> // Only <b class="">Foo</b> unqualified, others under <b class="">L</b> like <b class="">L.bar</b></font><span style="font-family: Menlo;" class="">.</span></div><div class=""><font face="Menlo" class=""><b class="">import Lib as L ()</b> // Everything must be qualified under <b class="">L</b> like <b class="">L.Foo</b> etc.</font></div><div class=""><font face="Menlo" class=""><b class="">import Lib as L hiding (qux)</b> // ..., qux must be qualified like <b class="">L.qux</b>.</font></div><div class=""><br class=""></div><div class="">Wouldn't that work pretty nicely, with minimal additions to syntax?</div><div class=""><br class=""></div><div class="">— Pyry</div><div class=""><br class=""></div><div class="">P.S. Okay, I can come up with a somewhat contrived corner case: What to do with modules whose names collide with type names imported unqualified, e.g. <a href="https://github.com/robrix/Either" class="">https://github.com/robrix/Either</a> ?</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">import Lib <b class="">//</b> defines bar like above <b class="">(1)</b></font></div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">struct Lib {</font></div><div class=""><font face="Menlo" class=""> </font><span style="font-family: Menlo;" class="">static func bar() {} <b class="">// (2)</b></span></div><div class=""><font face="Menlo" class="">}</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class=""><b class="">Lib.bar()</b> // Which one gets called, (1) or (2)?</font></div><div class=""><br class=""></div><div class="">One might suggest the above call resolved to the locally defined function. How about if <font face="Menlo" class="">struct Lib</font> was defined in another module that was also imported?</div></body></html>