<div dir="ltr">Right, the proposal in its current form does not really aim to resolve such conflicts, although it makes them occur less often by &quot;merging&quot; precedence and associativity when possible.<div><br></div><div>At first, I also tried to resolve such conflicts by naming operators. But I found that compiler instructions will be too complex in some cases:</div><div><br></div><div>#operator(+, name: numericAdd, fixity: infix, associativity: left)</div><div>#operator(+, name: arrayAppend, fixity: infix, associativity: right)</div><div><br></div><div>func numericAdd(left: A, right: B) -&gt; C</div>func numericAdd(left: B, right: C) -&gt; B<div>func arrayAppend(left: A, right: A) -&gt; B</div><div><div class="gmail_extra">func arrayAppend(left: B, right: C) -&gt; A</div><div class="gmail_extra"><br></div><div class="gmail_extra">A() + B() + C()</div><div class="gmail_extra"><br></div><div class="gmail_extra">Compiler will have to find by brute-force that this expression can only represent arrayAppend(A(), arrayAppend(B(), C())), and others result in errors. To me, this scheme seems pretty absurd.</div><div class="gmail_extra"><br></div><div class="gmail_extra">That said, it might be a good idea to add visibility for operators.</div><div class="gmail_extra">Hiding already imported operators, on the other hand, would be inconsistent with othr elements of the language. It is currently impossible to hide contents of module A from C where C imports B and B imports A. Not that I&#39;m against such a feature in general.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">- Anton</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-04-03 14:26 GMT+03:00 Ross O&#39;Brien <span dir="ltr">&lt;<a href="mailto:narrativium+swift@gmail.com" target="_blank">narrativium+swift@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">There is a problem here of duplicated operators or custom precedence, and how that gets passed between modules.<div>Assume there are three modules, A, B and C. B defines a custom operator **. A and C each define a custom operator ++, and their meanings are different (though, even if their meanings were the same, I&#39;m not sure if they could unify).</div><div><br></div><div>Module D uses A and B as dependencies and sets a custom precedence on ++ and **. Module E uses B and C and has a different precedence on ++ and **. You&#39;re working on Module F which uses D and E. Which ++ and which precedence does F get implicitly?</div><div><br></div><div>I&#39;m wondering whether we can treat operators the way we recently decided to treat selectors: if there is an ambiguity, it should be possible not just to specify which module they came from, but their fixity or argument types. If module D decides that &#39;++&#39; should refer to &#39;traditional postfix number incrementation&#39;, and F decides that it should be an infix &#39;conjoin two numbers as a string and turn the result into a number (e.g. 5 ++ 4 -&gt; 54)&#39; then a #selector-like operator signature would come in really handy.</div></div></blockquote></div><br></div></div></div>