<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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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. &nbsp;I'm not sure of too many Swift authors who would put something like that too high on their list of concerns, so +1. &nbsp;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>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; // 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="">&nbsp; &nbsp;// 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&nbsp;</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="">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// 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="">&nbsp;// Everything but&nbsp;<b class="">baz</b>&nbsp;works unqualified</span><span style="font-family: Menlo;" class="">, and all like&nbsp;</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>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// Import all unqualified, allow qualification under <b class="">L</b> like&nbsp;<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>&nbsp; &nbsp;// Only <b class="">Foo</b> unqualified, others under&nbsp;<b class="">L</b>&nbsp;like&nbsp;<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>&nbsp; &nbsp; &nbsp; // Everything must be qualified under <b class="">L</b> like&nbsp;<b class="">L.Foo</b>&nbsp;etc.</font></div><div class=""><font face="Menlo" class=""><b class="">import Lib as L hiding (qux)</b>&nbsp;// ..., 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.&nbsp;<a href="https://github.com/robrix/Either" class="">https://github.com/robrix/Either</a>&nbsp;?</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">import Lib&nbsp;<b class="">//</b>&nbsp;defines bar like above&nbsp;<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="">&nbsp; &nbsp;&nbsp;</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>&nbsp;// 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>