I know that the compiler can't read my mind. I don't mean to be frustrating.
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. 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.) > import Foo > import Bar > > using Foo.Baz; // in case of ambiguity, pick Foo.Baz > using extension Bar.Date; // in case of ambiguity on any Date extension > method, pick the one in Bar > using extension Foo.Date.frob; // except for frob, that one comes from Foo I know that this has problems on its own. Notably, `using` can't be a contextual keyword, the identifier now has to be reserved. Félix > Le 20 juil. 2016 à 23:51:15, Robert Widmann <[email protected]> a écrit : > > >> On Jul 20, 2016, at 9:37 PM, Félix Cloutier via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> 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". >> > > 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? > >> Félix >> >>> Le 20 juil. 2016 à 20:46:18, Robert Widmann <[email protected] >>> <mailto:[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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
