<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 Aug 2, 2016, at 10:30 AM, Nevin Brackett-Rozinsky 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="">Speaking for myself, I will *never* remember which of `&&` and `||` has higher precedence.</div></div></blockquote><div><br class=""></div><div>I had the opposite experience. The point here is don’t rob others for our own conveniences, which are definitionally subjective.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""> I think of them as peers, so I always use parentheses around them, and whenever I read code that mingles them without parentheses its meaning is *unclear* to me.<div class=""><br class=""></div><div class="">One of Swift’s main goals is clarity at the point of use. After all, code is read far more often than it is written. To me, an expression like `a && b || c && d` is not clear when I read it.</div><div class=""><br class=""></div><div class="">The same goes for bitwise operators: I view them as peers. I do not think of them as “additive” or “multiplicative” (and definitely not “subtractive”), so code that relies on their precedences will always send me scrambling to look up which comes first.</div><div class=""><br class=""></div><div class="">Certainly something like `a + b | c & d - e * f ^ g` is meaningless to me without parentheses.</div><div class=""><br class=""></div><div class="">Nevin</div><div class=""><br class=""></div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Aug 2, 2016 at 12:08 PM, Xiaodi Wu via swift-evolution <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">That's an excellent point, actually. Would there be downsides not yet considered?<div class="HOEnZb"><div class="h5"><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Aug 2, 2016 at 11:03 Félix Cloutier <<a href="mailto:felixcca@yahoo.ca" target="_blank" class="">felixcca@yahoo.ca</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">These expressions mix two types of logic that have different implications. For instance, `a * 16` and `a << 4` are "mostly equivalent", except that `a * 16` will crash on overflow. In these cases, I find that grouping provides some visual insulation that groups off the somewhat subtle differences.<div class=""></div></div><div style="word-wrap:break-word" class=""><div class=""><div class="">
<br class=""><span style="font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline !important;" class="">Félix</span>
</div></div></div><div style="word-wrap:break-word" class=""><div class="">
<br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 2 août 2016 à 08:49:07, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> a écrit :</div><br class=""><div class=""><div dir="ltr" style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">On Tue, Aug 2, 2016 at 10:41 AM, Félix Cloutier<span class=""> </span><span dir="ltr" class=""><<a href="mailto:felixcca@yahoo.ca" target="_blank" class="">felixcca@yahoo.ca</a>></span><span class=""> </span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><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 style="word-wrap:break-word" class="">I don't think that "intuitive" or "non-intuitive" is what you'd be looking for. There is nothing intuitive about multiplications having a higher precedence than additions; it's just a matter of conventions. I'm not a maths expert (as Stephen showed, I didn't even give the right explanation to binary operators!), but it seems to me that there could well be a parallel universe in which additions have precedence over multiplications without other serious implications.<div class=""><br class=""></div><div class="">And as it happens, a majority of people don't know that there is one for binary operators. I believe that the right question should be: do we want to pretend that this convention doesn't exist, to the benefit of people who don't know about it, and the detriment of those who do? Also, do we want to break it for && and || too?</div><div class=""><br class=""></div><div class="">I think that the biggest use case for binary operators in other languages are flags, and in Swift we treat these as collections. I'd venture that &, | and ^ would show up about as frequently as UnsafePointers and the like. It seems to me that Swift's approach has been to make things easy by default without locking away the power tools, and my personal expectation is that if you have to write code that has binary operators despite everything else that Swift has for you, you can be bothered to learn a precedence rule.</div><div class=""><br class=""></div><div class="">That said, one thing that I could definitely get behind is breaking precedence between binary operators and arithmetic operators. I don't think that it makes sense to write something like "a & b / c". Looking at my code, the only place where I needed to mix binary operators and arithmetic operators were `a & (a - 1)` (results in 0 if a is a power of two), and that one needs parentheses anyway.</div></div></blockquote><div class=""><br class=""></div><div class="">Although here, your same argument applies. If you need to write `a & b / c`, then you can be bothered either to learn or look up a table, or you can just put in the parenthesis yourself. Likewise, if you're a reader of the code, it's highly likely that this is a complex formula anyway; you can either know the relative precedence or look it up, but that's the *least* of your worries in terms of what it will take to understand that code. I see no reason to force parentheses unless it actually prevents user error.</div><div class=""> </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"><div style="word-wrap:break-word" class=""><div class=""><span class=""><font color="#888888" class=""><br class=""><div class=""><br class=""><span style="font-family:'Lucida Grande';font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">Félix</span></div></font></span><div class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 2 août 2016 à 02:29:41, Anton Zhilin <<a href="mailto:antonyzhilin@gmail.com" target="_blank" class="">antonyzhilin@gmail.com</a>> a écrit :</div><br class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">2016-08-02 7:18 GMT+03:00 Félix Cloutier<span class=""> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="">I disagree. The binary operators have properties that are comparable to arithmetic operators, and their precedence is easy to define as such. & has multiplication-like properties (0*0=0, 0*1=0, 1*0=0, 1*1=1); | has addition-like properties (0+0=0, 0+1=1, 1+0=1, 1+1=2); ^ has subtraction-like properties (0-0=0, 0-1=-1, 1-0=1, 1-1=0), and their precedences are set accordingly (& is multiplicative, | and ^ are additive).<div class=""><div class=""><br class=""></div><div class="">The same applies to && and ||. Bit shifts are exponentiative.<br class=""></div></div></div></blockquote><div class=""><br class=""></div>I believe that such way of thinking is non-intuitive. In C, bitwise operators are not intervened by any others, except for comparison operators (agreed, it was a mistake). We now have possibilities to do so in Swift, even better. I suggest to branch off right before AdditionPrecedence:<div class=""><br class=""></div><div class="">RangeFormation < Addition < Multiplication</div><div class="">RangeFormation < BitwiseOr < BitwiseAnd < LogicalShift</div><div class=""><br class=""></div><div class="">Another concern is NilCoalescing, which can be though to be semantically similar to Ternary. And at the same time it looks like || and &&, which would bring it between LogicalConjunction and Comparison.</div><div class="">Also, do Casting and RangeFormation stand where they should?</div><div class=""><br class=""></div><div class="">Next, Ternary operator is unique. Noone would ever like to put operators in this precedence group, because it would be confusing. Why not simplify our model and say that ?: has lower precedence than all binary operators, including Assignment? Unary > binary > ternary, sounds good? </div></div></div></div></div></blockquote></div></div></div></div></div></blockquote></div></div></div></div></blockquote></div><br class=""></div></div></blockquote></div>
</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>