> On Jun 9, 2016, at 3:04 AM, Jordan Rose <[email protected]> wrote: > > >>> 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]>: >>>> >>>> >>>> On Jun 7, 2016, at 9:47 PM, Thorsten Seitz <[email protected]> wrote: >>>> >>>> >>>> >>>> Am 07.06.2016 um 20:11 schrieb L Mihalkovic via swift-evolution >>>> <[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.
Yes, I'm sorry. i should have written my example the other way around to show that swift consistently chooses specific over implied. > > (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).) > > 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
