> Am 07.06.2016 um 20:11 schrieb L Mihalkovic via swift-evolution > <swift-evolution@swift.org>: > > 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 > > T3 ======= > import Lib1 > import func Lib2.func2 > var str = “str”.allCaps() // ERROR : ambiguous name > > > Lib1 =========== > public func func2() -> String { > return "lib1" > } > // only during T3 > public extension String { > public func allCaps() -> String { > return “lib1_" > } > } > > Lib2 =========== > public func func2() -> String { > return "lib2" > } > // only during T3 > public extension String { > public func allCaps() -> String { > return "lib2_" > } > } > > > T3 shows how differently extensions are treated from all other > exportable/importable artifacts: extensions are NOT sensitive to the scope > of imports. they are fully loaded as soon as the loader detects that the > module is referenced (they come from their own table inside the module > binary). > > > > >>> On Jun 7, 2016, at 6:45 PM, Paul Cantrell <cantr...@pobox.com> wrote: >>> >>> >>>> On Jun 7, 2016, at 11:36 AM, Paul Cantrell via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> >>>> On Jun 7, 2016, at 10:47 AM, L. Mihalkovic via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>>> On Jun 7, 2016, at 4:53 PM, Tony Allevato <allev...@google.com> wrote: >>>>> >>>>> I like the "from" keyword the best, but I'll take my own stab at a >>>>> modification: >>>>> >>>>> import ModuleA >>>>> import ModuleB >>>>> >>>>> "hello world".(capitalized from ModuleA)() >>>>> "hello world".(capitalized from ModuleB)() >>>>> "hello world".(someProperty from ModuleA) >>>>> "hello world".(someProperty from ModuleB) >>>> >>>> Hmmm... looks like an oxymoron in its own right... I was under the >>>> impression so far that the point of extensions was that they are not tied >>>> to a source. This brings us back full circle to the very definition of >>>> extensions... However you slice it, swift is lacking some scoping bellow >>>> modules, and/or arround some of the language features. >>> >>> IIRC, a member of the core team (Joe Groff, maybe?) indicated several >>> months ago on the list that methods are internally namespaced to their >>> module. Alas, I can’t find that message. It was a long time ago. >> >> Ah, here it is: >> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000928.html >> >> Joe Groff wrote: >> >> “It's helpful to think of method names as being namespaced in Swift, by both >> their enclosing module and type. If two modules independently extend a >> protocol with a method of the same name, you still semantically have two >> distinct methods that dispatch independently. The extension would have to be >> factored into a common module both modules see for them to interact.” >> >> IOW, yes, Swift internally does something very much like "hello >> world”.ModuleA::capitalized(). >> >>> You can see this in the fact that two different files can see two different >>> extension methods: >>> >>> A.swift >>> >>> import ModuleA >>> … >>> "hello world".capitalized() >>> >>> B.swift >>> >>> import ModuleB >>> … >>> "hello world".capitalized() >>> >>> …even if they end up compiled into the same binary. And that makes sense: >>> A.swift only expected to see ModuleA’s extension, and was presumably coded >>> around that expectation. That ModuleB happened to end up mixed into the >>> same binary shouldn’t change the behavior of A.swift >>> >>> If my understand is correct, then my "hello world”.ModuleA::capitalized() >>> and your "hello world".(capitalized from ModuleA)() are both just syntax to >>> expose something that Swift already tracks internally. >>> >>> Cheers, P >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution