<div dir="ltr">I like the "from" keyword the best, but I'll take my own stab at a modification:<div><br></div><div> import ModuleA</div><div> import ModuleB</div><div><br></div><div> "hello world".(capitalized from ModuleA)()</div><div> "hello world".(capitalized from ModuleB)()</div><div> "hello world".(someProperty from ModuleA)</div><div> "hello world".(someProperty from ModuleB)<br></div><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> "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> "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 <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
>> 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>
>><br>
>> import ModuleA<br>
>> import ModuleB<br>
>><br>
>> ("hello world" as ModuleA.String).capitalized() // Swift.String, with only APIs known to ModuleA<br>
>> ("hello world" as ModuleB.String).capitalized() // Swift.String, with only APIs known to ModuleB<br>
>> "hello world".capitalized() // Still causes a compile-time error for ambiguity<br>
><br>
> This only introduces a new kind of ambiguity since you can have both ModuleA and ModuleB declare something like<br>
><br>
> class String {<br>
> /// ...<br>
> }<br>
><br>
> And now you have no idea if ModuleA.String refers to Swift.String extension in ModuleA or class String in ModuleA.<br>
><br>
<br>
Keep in mind that extensions are not types. (See prev response)<br>
<br>
><br>
><br>
>><br>
>> --<br>
>> Brent Royal-Gordon<br>
>> Architechies<br>
>><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>
><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>
_______________________________________________<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>