<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 7, 2016, at 10:47 AM, L. Mihalkovic via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><div class=""><div dir="auto" class=""><div class=""><br class="">On Jun 7, 2016, at 4:53 PM, Tony Allevato &lt;<a href="mailto:allevato@google.com" class="">allevato@google.com</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">I like the "from" keyword the best, but I'll take my own stab at a modification:<div class=""><br class=""></div><div class="">&nbsp; &nbsp; import ModuleA</div><div class="">&nbsp; &nbsp; import ModuleB</div><div class=""><br class=""></div><div class="">&nbsp; &nbsp; "hello world".(capitalized from ModuleA)()</div><div class="">&nbsp; &nbsp; "hello world".(capitalized from ModuleB)()</div><div class="">&nbsp; &nbsp; "hello world".(someProperty from ModuleA)</div><div class="">&nbsp; &nbsp; "hello world".(someProperty from ModuleB)<br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote></div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class="">You can see this in the fact that two different files can see two different extension methods:</div><div class=""><br class=""></div><div class="">A.swift</div><div class=""><br class=""></div><div class=""><div dir="auto" class=""><div class=""><div dir="ltr" class=""><div class="">&nbsp; &nbsp; import ModuleA</div><div class="">&nbsp; &nbsp; …</div><div class="">&nbsp; &nbsp; "hello world".capitalized()</div><div class=""><br class=""></div><div class="">B.swift</div></div></div></div></div><div class=""><div dir="auto" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><div class=""><div dir="auto" class=""><div class=""><div dir="ltr" class=""><div class="">&nbsp; &nbsp; import ModuleB</div><div class="">&nbsp; &nbsp; …</div><div class="">&nbsp; &nbsp; "hello world".capitalized()</div></div></div></div></div><div class=""><div dir="auto" class=""><div class=""><div dir="ltr" class=""></div></div></div></div></div></div></div></div></div><div class=""><br class=""></div><div class="">…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</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Cheers, P</div><div class=""><br class=""></div></body></html>