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. Félix > Le 2 août 2016 à 02:29:41, Anton Zhilin <antonyzhi...@gmail.com> a écrit : > > 2016-08-02 7:18 GMT+03:00 Félix Cloutier <swift-evolution@swift.org > <mailto:swift-evolution@swift.org>>: > 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
