> On Jun 8, 2016, at 12:02, Thorsten Seitz via swift-evolution > <[email protected]> wrote: > >> >> Am 07.06.2016 um 22:27 schrieb L Mihalkovic <[email protected] >> <mailto:[email protected]>>: >> >>> >>> On Jun 7, 2016, at 9:47 PM, Thorsten Seitz <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> Am 07.06.2016 um 20:11 schrieb L Mihalkovic via swift-evolution >>> <[email protected] <mailto:[email protected]>>: >>> >>>> T1 ======= >>>> import Lib1 >>>> var str = func2() // lib1 >>>> >>>> T2 ======= >>>> import Lib1 >>>> import func Lib2.func2 >>>> var str = func2() // lib2 >>> >>> Shouldn't func2() be ambiguous here? It is imported from Lib1 and from Lib2. >>> >>> -Thorsten >> >> >> no, that is precisely the point .. it works!! I am able to override >> whatever my laziness brought into scope from Lib1 (caused by my * import) >> with a meticulously chosen implementation from Lib2. It is brilliant. >> extensions on the other hand work differently (although something could >> undoubtedly be done about them, I cannot entirely convince myself that it is >> time well spent. It would be if that could be a stepping stone form >> something else (which I have not been able to identify so far). > > So it is dependent on the order of the imports? That’s rather fragile IMO and > I would prefer having to solve clashes explicitly independent of import > order, e.g. by having to hide the version from Lib1: > > import Lib1 hiding func2 // strawman syntax > import func Lib2.func2
It doesn’t depend on the order, but it does consider naming a specific top-level value to be a “better” choice than importing the whole module, on the grounds that you wouldn’t have written it that way otherwise. (I’ve been lukewarm on the entire feature of selective imports for a while since there are often a lot of helpers in the same module (think UITableView and UITableViewDataSource). We do seem to be gravitating towards making helper things nested, though (see SE-0086 <https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md>).) This is getting a little off-topic from the problem of disambiguating members, though. Jordan
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
