~Robert Widmann
2016/07/21 8:17、Félix Cloutier <[email protected]> のメッセージ: > 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 don't understand this at all. The point of using and hiding is we create a file-local subset of identifiers you want to see. Bridging headers do not change that. I don't see how this is an example that affirmative is the *only* way to pick identifiers out of modules. > > 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.) Halfway there. Why is hiding such an issue? Explain to me how with only using imports you can recreate the "import String without String.UTF8View" example in the proposal. > >> 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]> 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]> a >>>> écrit : >>>> >>>> >>>> >>>> ~Robert Widmann >>>> >>>> 2016/07/20 20:07、Félix Cloutier via swift-evolution >>>> <[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, 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
