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.
Félix > Le 2 août 2016 à 08:49:07, Xiaodi Wu <[email protected]> a écrit : > > On Tue, Aug 2, 2016 at 10:41 AM, Félix Cloutier <[email protected] > <mailto:[email protected]>> wrote: > 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. > > 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? > > 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. > > 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. > > 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. > > > > Félix > >> Le 2 août 2016 à 02:29:41, Anton Zhilin <[email protected] >> <mailto:[email protected]>> a écrit : >> >> 2016-08-02 7:18 GMT+03:00 Félix Cloutier <[email protected] >> <mailto:[email protected]>>: >> 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). >> >> The same applies to && and ||. Bit shifts are exponentiative. >> >> 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: >> >> RangeFormation < Addition < Multiplication >> RangeFormation < BitwiseOr < BitwiseAnd < LogicalShift >> >> 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. >> Also, do Casting and RangeFormation stand where they should? >> >> 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?
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
