<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="">I know that the compiler can't read my mind. I don't mean to be frustrating.</div><div class=""><br class=""></div><div class="">If Foundation is imported in the bridging header of a project (as it is today, by default, in Swift framework projects), you get all of Foundation in all of your Swift code without a chance to write "import Foundation hiding (...)" anywhere. This reinforces my position that types should be selected affirmatively.</div><div class=""><br class=""></div><div class="">I'm not proposing a better solution because I don't have one right now. But if it would help appease you that I suggest something: keep "import using", let go of "hiding", and reuse the "using" keyword to select symbols from specific modules to break ambiguities. (Names must always be module-qualified to break ambiguities with classes that have the same name as a module.)</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">import Foo</div><div class="">import Bar</div><div class=""><br class=""></div><div class="">using Foo.Baz; // in case of ambiguity, pick Foo.Baz</div><div class="">using extension Bar.Date; // in case of ambiguity on any Date extension method, pick the one in Bar</div><div class="">using extension Foo.Date.frob; // except for frob, that one comes from Foo</div></blockquote><div class=""><br class="webkit-block-placeholder"></div><div class="">I know that this has problems on its own. Notably, `using` can't be a contextual keyword, the identifier now has to be reserved.</div><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 20 juil. 2016 à 23:51:15, Robert Widmann <<a href="mailto:rwidmann@apple.com" class="">rwidmann@apple.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 20, 2016, at 9:37 PM, Félix Cloutier 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">The problem is that by specifying "import Foo using (Baz)", I get nothing else from Foo. If I only want to exclude one conflicting name, I would have:</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">import Foo</div><div class="">import Bar hiding (Baz)</div></blockquote><div class=""><br class=""></div><div class="">In case of a conflict, my "internal monologue" is more like "take Baz from Foo" than "don't take Baz from Bar".</div><div class="">
<br class="Apple-interchange-newline"></div></div></div></blockquote><div class=""><br class=""></div><div class="">How else would you resolve an ambiguity than by selecting the appropriate declaration and hiding the others? Swift’s semantic analysis cannot read your mind, and neither can your (or mine) proposal for renaming syntax - in that you still have to import both modules either way. You may as well be explicit about which name you’re actually using and which ones you’re actually hiding, eh?</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><span style="font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Félix</span>
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 20 juil. 2016 à 20:46:18, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span class=""></span></div><div style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><br class=""><br class="">~Robert Widmann</div><div class=""><br class="">2016/07/20 20:07、Félix Cloutier via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">My understanding is that we want "using" and "hiding" because we want the ability to either take just a few things OR leave out just a few things. With a unified "import Foo (A = B, C = D, E = _) syntax, we only get the ability to take a few things AND hide a few things.</div></blockquote><div class=""><br class=""></div><div class="">Again, renaming is not something I want done with the same syntax as introducing and removing things from scope because they are distinct operations. This import tells me nothing from a semantic perspective and just seems easy to type rather than understand. Nowhere in the language can you find something that resembles this either.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">I've never really been into a case where I badly had to *not* import a name, so while I see why it makes sense from a mathematical perspective to have "hiding", I'm not sure how much I'd miss it if it wasn't there.</div></div></blockquote><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">I realize that it <a href="https://bugs.swift.org/browse/SR-898" class="">solves the ambiguous type problem</a>, but I consider that it's a flawed solution. Instead of specifying from which module you want an import, you have to specify on which modules you don't want it.</div></div></blockquote><div class=""><br class=""></div>You still specify which module you want to import from, so I don't see your point here. Given that Foo and Bar both define a class Baz, here's your import<div class=""><br class=""></div><div class="">import Foo using (Baz)</div><div class="">import Bar hiding (Baz)</div><div class=""><br class=""></div><div class="">What's the problem here? Isn't this exactly what you wanted to say in English (or whatever internal monologue you might have) spelled out in code? It scales immediately to multiple ambiguities and we can provide diagnostics to insert or remove identifiers in these lists to help the user out when they get stuck with an insufficiently inclusive or exclusive import list. The Python example is much more difficult to reason about from my perspective and from the perspective of the compiler. In fact, it's almost the code that's needed<span class="Apple-converted-space"> </span><i class="">today</i><span class="Apple-converted-space"> </span>to work around this problem - we're trying to fix the need for this here.</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">To see if we can get inspiration, I'd like to pitch an imperfect Python-like approach, where you could import a module as a namespace (and then you'd always have to write Module.Class, with modules systematically shadowing classes in the global namespace), or in addition to that, import every top-level name in the module into the file's global namespace. Names defined in multiple modules remain ambiguous unless explicitly shadowed:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">private typealias OrderedSet = BTree.OrderedSet</blockquote><blockquote type="cite" class="">private var foo: (Int) -> Int = Bar.foo<br class=""></blockquote><br class=""></div><div class="">You would not be allowed to shadow a module with a class.</div><div class=""><div class=""><br class=""></div><div class="">This, however, still does not solve the extension problem. Additionally, given that the default visibility for top-level names is internal, careless users could easily pollute the project's global namespace. Finally, for micro-frameworks that have a class with the same name as a module, you'd always have to write Name.Name, since the class can't shadow the module.</div><div class=""><div class=""><div class=""><div class=""><br class="Apple-interchange-newline"><span class="" style="font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">Félix</span></div></div></div></div></div></div></blockquote></div></div></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>