<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On Jun 7, 2016, at 4:53 PM, Tony Allevato &lt;<a href="mailto:allevato@google.com">allevato@google.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I like the "from" keyword the best, but I'll take my own stab at a modification:<div><br></div><div>&nbsp; &nbsp; import ModuleA</div><div>&nbsp; &nbsp; import ModuleB</div><div><br></div><div>&nbsp; &nbsp; "hello world".(capitalized from ModuleA)()</div><div>&nbsp; &nbsp; "hello world".(capitalized from ModuleB)()</div><div>&nbsp; &nbsp; "hello world".(someProperty from ModuleA)</div><div>&nbsp; &nbsp; "hello world".(someProperty from ModuleB)<br></div></div></div></blockquote><div><br></div><div>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><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>The "from" keyword makes it clearer than arbitrary punctuation what's going on, and extending the member reference syntax to support ".(member from Module)" seems clearer than putting the "from Module" after the actual call; we're saying "look up the member named 'member' on the receiver's type inside Module", as opposed to having it look like the "from" applies to the *expression*, which it doesn't.</div><div><br></div><div>Having the parens there is helpful in the property disambiguating case, where we would otherwise have this:</div><div><br></div><div><div>&nbsp; &nbsp; "hello world".someProperty from ModuleB.bar<br></div><div><br></div></div><div>Is that a property "bar" on the result of "someProperty" from ModuleB, or is that "someProperty" from submodule ModuleB.bar? This removes the ambiguity:</div><div><br></div><div>&nbsp; &nbsp; "hello world".(someProperty from ModuleB).bar<br><br class="inbox-inbox-Apple-interchange-newline"></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 7, 2016 at 7:27 AM LM via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
&gt;&gt; We already have the concept of prefixing a type name with a module to disambiguate when two modules have the same type. I wonder if we could do the same thing to disambiguate between conflicting extensions?<br>
&gt;&gt;<br>
&gt;&gt;&nbsp; &nbsp; import ModuleA<br>
&gt;&gt;&nbsp; &nbsp; import ModuleB<br>
&gt;&gt;<br>
&gt;&gt;&nbsp; &nbsp; ("hello world" as ModuleA.String).capitalized()&nbsp; &nbsp; // Swift.String, with only APIs known to ModuleA<br>
&gt;&gt;&nbsp; &nbsp; ("hello world" as ModuleB.String).capitalized()&nbsp; &nbsp; // Swift.String, with only APIs known to ModuleB<br>
&gt;&gt;&nbsp; &nbsp; "hello world".capitalized()&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; // Still causes a compile-time error for ambiguity<br>
&gt;<br>
&gt; This only introduces a new kind of ambiguity since you can have both ModuleA and ModuleB declare something like<br>
&gt;<br>
&gt; class String {<br>
&gt;&nbsp; &nbsp; /// ...<br>
&gt; }<br>
&gt;<br>
&gt; And now you have no idea if ModuleA.String refers to Swift.String extension in ModuleA or class String in ModuleA.<br>
&gt;<br>
<br>
Keep in mind that extensions are not types. (See prev response)<br>
<br>
&gt;<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Brent Royal-Gordon<br>
&gt;&gt; Architechies<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; swift-evolution mailing list<br>
&gt;&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</div></blockquote></body></html>