<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 8, 2016, at 12:33 PM, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I agree that operator syntax needs to be reworked, but I prefer that whatever proposal ends up being accepted not abuse the word 'fixity' to mean something it doesn’t.</div></div></blockquote><div><br class=""></div><div>I can’t say with certainty whether “fixity” is cromulent or incromulent ;-), but how about: “position” or “placement”?</div></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Mar 8, 2016 at 12:13 PM, Антон Жилин <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="">There have been complaints on current syntax of operator declarations:</div><div class=""><br class=""></div><div class="">infix operator <> { associativity left precedence 100 assignment }</div><div class=""><br class=""></div><div class="">It looks like a collection of random words. Dictionary syntax would suit better here. Additionally, `assignment` has been deprecated for a long time, but not removed.</div><div class=""><br class=""></div><div class="">Many syntaxes were suggested. For example:</div><div class=""><br class=""></div><div class="">#operator(<>, fixity: infix, associativity: left, precedence: 100)</div><div class=""><br class=""></div><div class="">*But* Joe Groff uncovered a deeper problem. Current operators cannot be given precedence and associativity per concrete operator function.</div><div class=""><br class=""></div><div class="">Moreover, it makes more sense for operators to only allow parenthesis omission for some other operators. (C/C++ gives warnings for relying on precedence for unrelated operators.) </div><div class=""><br class=""></div><div class="">Operator declarations may lie in different modules and not know anything about each other, but they will create a conflict if their names happen to be identical.</div><div class=""><br class=""></div><div class="">The following is my attempt at solving the problem.</div><div class=""><br class=""></div><div class="">1.</div><div class="">All operators are aliases for functions.</div><div class=""><br class=""></div><div class="">#operator(+, name: numericAdd, fixity: infix, associativity: left)</div><div class=""><br class=""></div><div class="">func numericAdd(left: Int, _ right: Int) -> Int</div><div class=""><br class=""></div><div class="">#operator(+, name: numericUnaryPlus, fixity: prefix)</div><div class=""><br class=""></div><div class="">func unaryPlus(right: Int) -> Int</div><div class=""><br class=""></div><div class="">+1 + 2 // same as numericAdd(numericUnaryPlus(1), 2)</div><div class=""><br class=""></div><div class="">2.</div><div class="">Operators with same "operator form" use overloading, modified to accomodate associativity and precedence.</div><div class=""><br class=""></div><div class="">#operator(+, name: append, fixity: infix)</div><div class=""><br class=""></div><div class="">func append<T>(left: [T], right: T) -> [T]</div><div class=""><br class=""></div><div class="">var arr = [1, 2, 3]</div>1 + 2 + 3 //=> 6<div class="">[1, 2] + 3 //=> 1 2 3</div><div class="">[1, 2] + 3 + 4 // error</div><div class=""><br class=""></div><div class="">Compiler must try to apply rules of both `numericAdd` and `append` in all combinations. Complexity of this should not be exponential: most branches will be cut off fast, starting from the inside.</div><div class=""><br class=""></div><div class="">In 1 + 2 + 3, `append` cannot be applied both to 1+2 and to 2+3, so we are left with `numericAdd`.</div><div class="">In [1,2] + 3 + 4, `numericAdd` cannot be applied to [1,2] + 3, and `append` cannot be applied to 3 + 4. But if we assume `append` and `numericAdd`, then no precedence rule is defined between `numericAdd` and `append`.</div><div class=""><br class=""></div><div class="">Overall, algorithm for compiler is to be developed.</div><div class=""><br class=""></div><div class="">3.</div><div class="">Operators can define precedence (omission of parentheses), only compared to other specific operators.</div><div class=""><br class=""></div><div class="">#precedence(append, lessThan: numericAdd)</div><div class=""><br class=""></div><div class="">#precedence(numericAdd, equalTo: numericSubtract)</div><div class=""><br class=""></div><div class="">4.</div><div class="">Precedence applies to unary operators as well:</div><div class=""><br class=""></div><div class="">let v: Bool? = false</div><div class="">let u = !v! // error, precedence between logicalNot and forceUnwrap is not defined</div><div class=""><br class=""></div><div class="">#precedence(forceUnwrap, greaterThan: logicalNot)</div><div class=""><br class=""></div><div class="">let u = !v! // true</div><div class=""><br class=""></div><div class="">That said, precedence of unary operators is always higher than of any binary operator.</div><div class=""><br class=""></div><div class="">- Anton</div></div>
<br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>