<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>You forgot one :-)</div><div><span class="pl-k" style="background-color: rgba(255, 255, 255, 0); box-sizing: border-box;">let</span><span style="background-color: rgba(255, 255, 255, 0);"> capitalizedA </span><span class="pl-k" style="background-color: rgba(255, 255, 255, 0); box-sizing: border-box;">=</span><span style="background-color: rgba(255, 255, 255, 0);"> ModuleA {</span></div><div><span class="pl-s" style="background-color: rgba(255, 255, 255, 0); box-sizing: border-box;"><span class="pl-pds" style="box-sizing: border-box;"> "</span>hello swift<span class="pl-pds" style="box-sizing: border-box;">"</span></span><span class="pl-k" style="background-color: rgba(255, 255, 255, 0); box-sizing: border-box;">.</span><span style="background-color: rgba(255, 255, 255, 0);">capitalized()</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">}</span></div><div><br><div>+1 on finding a way to explicitly resolve naming collisions. I'm generally in favor of something like #2 (or #3). A while back, there was a proposal to replace numerical operator precedence with a relative precedence system. I can't remember if it went through, but if so I would argue that the two systems should probably be the same, since they solve the same problem.</div></div><div><br><div>I would also suggest there be a way to import a module at a lower precedence than the current source file, for the purposes of "overriding" any top-level functions (or even types, I suppose).</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Something like "<span style="background-color: rgba(255, 255, 255, 0);">partially import ModuleA" would solve the problem as well, but I can't think of anything resembling a practical syntax for specifying which parts.</span><br><br>- Dave Sweeris </div><div id="AppleMailSignature"><br></div>On Jun 4, 2016, at 20:29, Paulo Faria via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">Hello, everyone.<br class=""><br class="">I want to discuss the problem of name ambiguity when a computed property or function is defined with the same name and type in different modules. Currently there’s no way to disambiguate the implementation in use cases similar to the one contained in the gist below.<br class=""><br class=""><a href="https://gist.github.com/paulofaria/f48d0b847a0fb7c125d163d0e349500a" class="">https://gist.github.com/paulofaria/f48d0b847a0fb7c125d163d0e349500a</a><br class=""><br class="">The gist also contains some informal proposals. The idea is to create a formal proposal based on the discussion that shall follow.<br class=""><br class="">Cheers, <br class="">Paulo</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>