<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Interesting model!<div class=""><br class=""></div><div class="">If I understand correctly: this changes the precedence from being based on a numeric value, to being represented as a bit of a DAG of precedence groups. A precedence group is defined implicitly for each operator, with one group around each set of operators where equalTo has been declared.</div><div class=""><br class=""></div><div class="">The groups are lazily evaluated, so if an expression can be resolved without ambiguity due to lack of reachability between two individual operators in the DAG, there is no issue/error.</div><div class=""><br class=""></div><div class="">Comments:</div><div class="">- I wonder if there are cases in the standard operators which would be better modeled as a non-linear chain. &nbsp;The compiler could warn around usage which is defined by operator precedence, but is commonly considered ambiguous or error prone.&nbsp;</div><div class=""><br class=""></div><div class="">For example, if users commonly get confused about the conjunctive and disjunctive levels (logical ‘and’ and ‘or’) being different levels with precedence, you could just omit the lessThan relationship between the two of them. The compiler would then error on ambiguous cases, prompting the user to use parenthesis.</div><div class=""><br class=""></div><div class="">- I’d prefer instead of operator precedence groups just being implicit by use of #precedence equalTo, that the operators are bound to a group explicitly. Something like</div><div class="">#precedence(+, group: “additive”)</div><div class="">#precedence(“additive”, lessThan: “multiplicative”)</div><div class=""><br class=""></div><div class="">However, this may create more issues than it solves (two frameworks creating their own custom operators, putting them in custom precedence groups, and the consumer decides the two precedence groups are really equivalent)</div><div class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Apr 3, 2016, at 3:36 AM, Антон Жилин via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Swift 2.2 is out, and I restart discussion on syntax for custom operators. I insist that this time we should focus less on linguistic aspects.<div class=""><br class=""></div><div class=""><a href="https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md" class="">https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md</a></div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></div></body></html>