Re: ternary operators--this goes far beyond the boundaries of the discussion you yourself started. Removing certain relative precedences so that parentheses are required is one thing; *changing* relative precedences is quite another. For me at least, the latter is an absolute nonstarter. Every existing usage of the operator could potentially *silently* break.<br><br>As to removing certain precedences--the current Swift precedences are rationally defensible. Perhaps anything you propose would be too, but trading one rational scheme for another (at best) is not justification enough for a source-breaking change. Instead, show me a scenario in which you write something today that could plausibly do something other than what it might look like, where forcing parentheses would fix the issue--i.e. convince me a change would eliminate actual user errors--and I'm on board. So far, I haven't seen one (even the "maybe" scenario above, a && b | c, wouldn't work in Swift unless you defined custom operator functions yourself, so there's no real possibility of a silent error).<br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 2, 2016 at 08:31 Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="white-space:pre-wrap">What's your evidence that it's non-intuitive? I literally use << for powers of 2, as I'm sure do many others. As in, 1 << 3 == 8. Do you have a better way of computing, say, 2^53?<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 2, 2016 at 04:29 Anton Zhilin <<a href="mailto:antonyzhilin@gmail.com" target="_blank">antonyzhilin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-08-02 7:18 GMT+03:00 Félix Cloutier <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span>:<br><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">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><div><br></div><div>The same applies to && and ||. Bit shifts are exponentiative.<br></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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><br></div><div>RangeFormation < Addition < Multiplication</div><div>RangeFormation < BitwiseOr < BitwiseAnd < LogicalShift</div><div><br></div><div>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>Also, do Casting and RangeFormation stand where they should?</div><div><br></div><div>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>
</blockquote></div></blockquote></div>