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:
> import Foo > import Bar hiding (Baz) In case of a conflict, my "internal monologue" is more like "take Baz from Foo" than "don't take Baz from Bar". Félix > Le 20 juil. 2016 à 20:46:18, Robert Widmann <[email protected]> a > écrit : > > > > ~Robert Widmann > > 2016/07/20 20:07、Félix Cloutier via swift-evolution > <[email protected] <mailto:[email protected]>> のメッセージ: > >> 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. > > 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. > >> >> 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. >> >> I realize that it solves the ambiguous type problem >> <https://bugs.swift.org/browse/SR-898>, 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. > > 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 > > import Foo using (Baz) > import Bar hiding (Baz) > > 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 today to work around this problem - we're trying to fix the need for > this here. > >> >> 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: >> >>> private typealias OrderedSet = BTree.OrderedSet >>> private var foo: (Int) -> Int = Bar.foo >> >> You would not be allowed to shadow a module with a 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. >> >> Félix
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
