<div dir="ltr">Sorry for breaking the thread, next time please mail me a copy :)<div>Link to the proposal:</div><div><a href="https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md" target="_blank">https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md</a></div><div><br></div><div><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">1.  I strongly agree that the numeric precedence system is not great. From<br>    a implementation point of view, the way to specify them in your proposal<br>    essentially gave all visible operators a partial order, in which we can<br>    draw a directed gragh with operators being the nodes and their relation<br>    being arcs. A part of the graph might look like: &#39;^&#39; --&gt; &#39;*&#39; --&gt; &#39;+&#39;, the<br>    nodes being the math operators. We can tell &#39;*&#39; has a higher precedence<br>    than &#39;+&#39;, &#39;^&#39; has a higher precedence than &#39;*&#39; and &#39;+&#39;, by follwing the<br>    arcs. If one operator is not reachable from another, and vice versa, then<br>    composing these two is illegal. We need to teach the compiler this concept.<br></blockquote><div> </div><div>Right, that semantics was actually the main driver of the proposal.</div><div><br></div><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">2.  Currently, it&#39;s not possible to specify precedence for pre- and postfix<br>    operators. Chris Lattner has mentioned that the<br>    following result is not desirable:<br>        ∆x + y<br>    … where ∆ has a lower precendence than + while it&#39;s required to have no<br>    space between ∆ and the operand. My understanding is that if spaces were<br>    to be allowed here, parsing such expression without ambiguity is a<br>    non-trivial challenge. So, will it be possible to specify precedence for<br>    pre/postfix operators under your proposal?<br></blockquote><div><br></div><div>No, I currently leave prefix and postfix operators unchanged (apart from syntax shuffling). I will add this as a future direction.</div><div>Prefix and postfix operators would behave the same as infix, but have higher precedence than any infix operator by default.</div><div>This feature, if added, would be non-breaking.</div><div> </div><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">3.  It may be a good exercise to work out how would each of the builtin<br>    operators would be defined with this change and mention it (not the entire<br>    definition, but the fact that it&#39;s possible, or reasons why it produces<br>    any difference) in the proposal.</blockquote><div><br></div><div>Operators `is`, `as`, `as?`, `as!`, which are not actually Swift custom operators (they contain letters), will not participate in this exercise. (Let&#39;s not discuss allowing letters in operators here.)</div><div>That being said, great idea. I will add example declarations of standard library operators.</div><div><br></div><div> - Anton</div></div></div>